Inner classes...

[Chad Slaughter]

Hello all,

Since we're on the topic of inner classes, I would like a
different perspective on the issue.

I have read the Java inner class spec and think the reasons they give
for inner classes are weak, and seem to be more of a last minute hack to
try and fix problems with their event model then anything productive or useful.
But I assume that someone finds them useful, and would like an explanation.
And from a object-oriented view, I would like to know how inner classes
don't violate encapsulation, as the appear to do.

Now this may not be the correct forum for this, but I would prefer to
not get lynched in the comp.lang.java.* groups for speaking such
blasphemy.  I am looking for solid reasons for the use of inner class.

I know this is long, but bear with me.
I would, like Dion, like to know what Mike plans to do with the inner
classes?  I think support as far as access to them it is inevitable, but
don't think support for creating them is all that worthwhile.

Later,

--
Chad Slaughter  -- slaught at umr.edu
<PGP public key available upon request>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[dIon Gillard/Multitask Consulting/AU]

> I have read the Java inner class spec and think the reasons they give
> for inner classes are weak, and seem to be more of a last minute hack to
> try and fix problems with their event model then anything productive or useful.
I think you're confusing anonymous inner classes and inner classes in
general. Inner classes are useful for more than just event handling.

> But I assume that someone finds them useful, and would like an explanation.
Definitely. They provide a way of encapsulating the namespace of
classes.

Consider a stack that wants to provide an Enumeration when elements() is
called.
The ability to enumerate the stack has nothing to do with the stack
class itself, and could be provided by another class. But, the 'other
class' would only ever be use by the stack class, and would be polluting
the namespace. Rather than calling it Enumerator, it would probably get
called StackEnumerator, which is a lot of fun when stack gets call
FifoStack in release 2.

With an inner class, you effectively 'hide' the Enumerator name inside
the inner class.

Check the JavaMail Message.Recipient class...maybe I have a transaction
that also has a Recipient class. Putting recipient into java.mail. would
make it visible to everyone who imported java.mail.*. Since recipient
has no meaning outside of a message, it's cleaner to encapsulate the
Recipient class inside it's 'parent' - Message.

> And from a object-oriented view, I would like to know how inner classes
> don't violate encapsulation, as the appear to do.
Non-static inner classes have access to private and protected
fields/methds etc. This violates encapsulation.
Static inner classes don't need a reference to their outer class, and
hence can't violate it.

> Now this may not be the correct forum for this, but I would prefer to
> not get lynched in the comp.lang.java.* groups for speaking such
> blasphemy.  I am looking for solid reasons for the use of inner class.
Is this any good?

> I know this is long, but bear with me.
> I would, like Dion, like to know what Mike plans to do with the inner
> classes?  I think support as far as access to them it is inevitable, but
> don't think support for creating them is all that worthwhile.
I really would like both :)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[dIon Gillard/Multitask Consulting/AU]

Chad Slaughter wrote:

>
> Dion Gillard wrote :>
> >I think you're confusing anonymous inner classes and inner classes in
> >general. Inner classes are useful for more than just event handling.
>
> I do understand the difference between the two, and find both without merit.
>
> >> But I assume that someone finds them useful, and would like an explanation.
> >Definitely. They provide a way of encapsulating the namespace of
> >classes.
>
> Wasn't that the point of packages???

Yes, but all classes in imported packages are effectively 'global
names'. I can't import two packages which have classes with the same
names reliably.

> >With an inner class, you effectively 'hide' the Enumerator name inside
> >the inner class.
>
> But the problem comes along when you have inner classes that are not
> private members of there outer class and can be accessed from the outside.
> This is my main concern.  I have no problem if you wish to implement a class
> with a member that is another class, but why do I have to see it?
Why is the inner class being public a problem? Could you explain this a
bit more...I can't see why it makes a difference?

Ok....so that means non-static inner classes are ok for you?

> Why are inner classes, allowed to be public?


> Also, the stack enumerator was a bad example in the spec, too. =)
Could you expand on why it's a bad example?

> >Check the JavaMail Message.Recipient class...maybe I have a transaction
> >that also has a Recipient class. Putting recipient into java.mail. would
> >make it visible to everyone who imported java.mail.*. Since recipient
> >has no meaning outside of a message, it's cleaner to encapsulate the
> >Recipient class inside it's 'parent' - Message.
>
> I disagree on whether its cleaner.  If it has no meaning outside of Message,
> then why is it even visible outside Message?  Why not make Recipient a private
> class in the package? I just don't see the advantage.
It's public because this recipient only applies to a message. Other
classes may need to send messages and indetify what types of recipients
they are sending it to. Recipient is only 'useful' when used with
Message. Making it package access would mean only other classes in the
package can use it - not useful for anyone wanting to send an email from
their own packages.

> >> And from a object-oriented view, I would like to know how inner classes
> >> don't violate encapsulation, as the appear to do.
> >Non-static inner classes have access to private and protected
> >fields/methds etc. This violates encapsulation.
> >Static inner classes don't need a reference to their outer class, and
> >hence can't violate it.
>
> So what advantage does inner class bring if they break one of the main points of
> Java?(ie object-orientation)
Again...you are focusing on one type of inner class, rather than inner
classes in general.
Substitute inheritance in your sentence?

So what advantage does inheritance bring if it breaks one of the main
points of Java?

> >Is this any good?
> Only partially.  It doesn't really answer my questions or my concerns, but
> maybe only Sun can do that.
I really need some more on your questions and concerns to go further....
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>

[dIon Gillard/Multitask Consulting/AU]

At 22:40 15/01/98 -0600, you wrote:

>>> Wasn't that the point of packages???
>>Yes, but all classes in imported packages are effectively 'global
>>names'. I can't import two packages which have classes with the same
>>names reliably.
>
>Some then you have just made a case for getting rid of the import statement,
>and forceing ppl to use the fully qualified names.  Which solves your
>problem. I don't see how inner classes helps here.
I don't think using only fully qualified names is a good solution. Inner
classes help by allowing you to define a class with scope, similar to a
package. The scope is part of the classes name. i.e. Message.Recipient is a
class, just like all others.

>>> >With an inner class, you effectively 'hide' the Enumerator name inside
>>> >the inner class.
>>>
>>> But the problem comes along when you have inner classes that are not
>>> private members of there outer class and can be accessed from the outside.
>>> This is my main concern.  I have no problem if you wish to implement a
class
>>> with a member that is another class, but why do I have to see it?
You may want to use the inner class. I think you're focusing on inner
classes as only a private implementation issue, when they're not. Public
inner classes are like public classes in a package...

>>Why is the inner class being public a problem? Could you explain this a
>>bit more...I can't see why it makes a difference?
>
>Because I then have to worry about the implimentation of class.
If it's a public class, you always have to worry about it, though. If it
was java.mail.MessageRecipient versus java.Mail.Message.Recipient (in inner
class), you'd still have to worry about it, no?

I still don't see the difference...it's just another scoping mechanism.
Classes in the same package are classes that are logically related. Inner
classes are only going to be used with their outer class in most cases,
they're just being scoped differently.

>So if a class decides to implimentate a feature with a class that is
>public, I(the user of the class) now ahve to worry about the internals
>of the object, I shouldn't have to do this, that is the whole point of
In this case, a public inner class is no more the internals of an object
than a public method or property.

>OO programing.  I have an interface that I use(public methods)
>that access data, in such a way that it is irrelevent to me how the
>class adn data are implimented, but inner classes, all of a sudden
>make the implimentation my problem.
Not at all...an inner class is just another public class

>>Ok....so that means non-static inner classes are ok for you?
>
>Sure, I  don't have to see private inner classes. Then I don't
>have to worry about the implimentation, etc.
'Private' inner classes are not the same as non-static ones. You can have a
public non-static inner class...

>>> Also, the stack enumerator was a bad example in the spec, too. =)
>>Could you expand on why it's a bad example?
>
>Becuase th e stack class could just as easily implimented the enumerated
>interface, and instead of having a "helper class".
But the point of the example was that the stack class considered as an
object in isolation, shouldn't be responsible for enumerating itself. The
enumeration interface has nothing to be with being a stack...So why should
it implement the interface, in an OO design sense?

>>> >Check the JavaMail Message.Recipient class...maybe I have a transaction
>>> >that also has a Recipient class. Putting recipient into java.mail. would
>>> >make it visible to everyone who imported java.mail.*. Since recipient
>>> >has no meaning outside of a message, it's cleaner to encapsulate the
>>> >Recipient class inside it's 'parent' - Message.
>>>
>>> I disagree on whether its cleaner.  If it has no meaning outside of
Message,
>>> then why is it even visible outside Message?  Why not make Recipient a
private
>>> class in the package? I just don't see the advantage.
>
>>It's public because this recipient only applies to a message. Other
>If recipient only applies to message is should be private.
So if recipient is private, how do I set the recipient for a message?????

>I understand the need to identify recipients, by why is recipient an
>object then??  Why not a set/get Recipients method on message?
What would you implement it as? It has a type, address etc? What would
setRecipient look like:

setRecipient(address, type)?
Would you make type an int? an Object?

>Why a seperate object?  I simply question there logic and design
>decisions in using inner class for the JavaMail.  I don't see a need
>for them here, I see SUn using inner class in JavaMail, to jsut be using
>Inner classses. No other real design reason.
It's a separate object because it encapsulates information about a
recipient. Data and methods..

>>> >> And from a object-oriented view, I would like to know how inner classes
>>> >> don't violate encapsulation, as the appear to do.
>>> >Non-static inner classes have access to private and protected
>>> >fields/methds etc. This violates encapsulation.
>>> >Static inner classes don't need a reference to their outer class, and
>>> >hence can't violate it.
>>>
>>> So what advantage does inner class bring if they break one of the main
points of

>>> Java?(ie object-orientation)
>
>>Again...you are focusing on one type of inner class, rather than inner
>>classes in general.
>
>Well seeing how publicly named, inner classes ARE the problem, that is
>why I am focusing on them.  As I said I have no problem with private inner
>classes, because I don't have to see them.  And languages like NetRexx don't
>have to deal with them, if they can't see them.
>
>>Substitute inheritance in your sentence?
>???
>>So what advantage does inheritance bring if it breaks one of the main
>>points of Java?
>
>Inheritance is a main point of object-oriented programming.
>I should have said what is the point of inner classes if they break a
>major point of object-oriented programming?  The "main" feature of java.

They allow a scoping of classes. They stop pollution of the global class
names when compiling code.

Think about packages - they too break encapsulation..

>>> Only partially.  It doesn't really answer my questions or my concerns, but
>>> maybe only Sun can do that.
>>I really need some more on your questions and concerns to go further....
>Well, thank you for trying. =)
I'm still trying.....
dIon Gillard
Sun Certified Java 1.1 Programmer
Work: http://www.multitask.com.au
NetRexx: http://www.multitask.com.au/netrexx
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To unsubscribe from this mailing list ( ibm-netrexx ), please send a note to
[hidden email]
with the following message in the body of the note
unsubscribe ibm-netrexx <e-mail address>