[2129] in java-interest
Re: AWT instance variables
daemon@ATHENA.MIT.EDU (Ed Grossman)
Mon Sep 25 23:45:24 1995
Date: Mon, 25 Sep 1995 20:16:49 -0500
To: Arthur van Hoff <Arthur.Vanhoff@Eng.Sun.COM>
From: egrossma@ncsa.uiuc.edu (Ed Grossman)
Cc: jag@Eng.Sun.COM, java-interest@java.Eng.Sun.COM
Arthur,
I can hardly believe that you are arguing that I should not be allowed to
provide such obviously useful items as a menu sorted by command name or an
object that, because of special knowledge of the structure in which it
existed, didn't need to use the standard "add" interface (along with the
accompanying update overhead) to set its own parent.
You claim this would "break" AWT. Perhaps this is the where we
misunderstand each other. I don't really see how adding subclasses could
break AWT; certainly the subclasses would not work properly unless they
were careful to clean up any messes they made by not following the standard
interfaces, but AWT itself and the classes comprising it would still be
inviolate, and any code using only AWT classes would work as advertised.
In object-oriented programming, there is always a tension between reuse and
encapsulation. The more that the internals are hidden, the harder it is to
make modifications to an object that were not foreseen by the original
developer. This is one reason the protected access specifier was created,
so that an object coudl present a completely encapsulated interface to
other classes while providing a less restricted interface to its own
subclass. By more or less ignoring the protected access specifier, you
have chosen to stay almost completely on the encapsulation side of the
spectrum, and by doing so, you make it almost impossible for any other
developers to extend the toolkit via inheritance.
In fact, it's clear that even the class hierarchy that your own toolkit
provides could not exist if it weren't for the odd default state that in
C++ terms, makes every class in the AWT package a friend of every other.
Look at the Container, which would not even be able to set the parents of
its children if it weren't for this feature.
In conclusion, I'd like to point out that if you expect the AWT to be used
for anything other than applet development, it will need to be extensible.
Any major project written in AWT will need additional user interface
components. Object-oriented toolkits generally allow extension in two ways
- inheritance and composition. By providing such a limited interface to
subclasses, you have effectively removed inheritance as an option. I urge
you to look at the class hierarchy provided by other object-oriented
toolkits, find a few classes that are related to ones in the AWT, but
somewhat different (so that it is natural to consider implementing them via
inheritance) and then determine whether you could in fact implement them
given the public AWT interface. I've already given you several examples.
Yours Truly,
Ed Grossman
NCSA
At 12:46 PM 9/25/95, Arthur van Hoff wrote:
>Hi Ed,
>
>> Here is a list of things that I, as a class designer, might want a subclass
>> of an AWT object to do, which cannot be done within the current framework
>> unless the new objects are part of the AWT package.
>>
>> 1) As a descendant of Component, set my parent directly. In fact, even the
>> "add" method of the Container object would not work if it were not in the
>> same package as Component.
>>
>> 2) As a descendant of Menu, change the order of my Menu items, or choose to
>> add a new item anyplace but the end of the menu.
>>
>> 3) As a descendant of Container, sort my children in place.
>
>Any of these operations would break the AWT if you would do them by
>directly accessing the instance variables. I'm glad we stopped you!
>
>> 4) As a descendant of FlowLayout, change my alignment.
>
>The fact that the layout objects have private variables is broken.
>I'll fix that.
>
>> I'm sure I could come up with more. Note that these are all things an
>> object would want to do to itself, not things it would allow other objects
>> to do. The way AWT is written, subclasses as a rule do not have any more
>> privileged access to their ancestors' instance variables (which could
>> really be thought of as their own instance variables) than any other class,
>> thus making AWT extremely difficult to extend.
>
>I disagree. It makes the AWT safer.
>
>> I'd like to know if this state of affairs is going to continue in future
>> releases.
>
>Absolutely!
>
>Have fun,
>
> Arthur van Hoff
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
