[2132] in java-interest
Re: AWT instance variables
daemon@ATHENA.MIT.EDU (Arthur van Hoff)
Mon Sep 25 23:59:54 1995
From: Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
To: egrossma@ncsa.uiuc.edu (Ed Grossman)
Date: Mon, 25 Sep 1995 18:53:34 -0800 (PDT)
Cc: jag@acorn.Eng.Sun.COM (James Gosling), java-interest@java.Eng.Sun.COM
In-Reply-To: <v02130502ac8cfb805ecc@[141.142.150.233]> from "Ed Grossman" at Sep 25, 95 08:16:49 pm
Hi Ed,
> 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.
The awt components have a platform depended counter part called their peer
components. These correspond to Motif components on Unix and actual Win32
components on the PC. If you were allowed to randomly change an AWT component's
state it would not be appropriatly reflected in the peer object.
> 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.
You can add as many subclasses as you like. As long as they stick the the
AWT APIs they will work fine! The only concern is that these subclasses can't
directly manipulate the internal state their superclasses. By the way, this
seems like a very common and useful OO methodology to me...
> 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.
Unless we provide total encapsulation you would be able to exploit platform
dependent behaviours by manipulating a component's state. We can't guarantee
consitency across platforms that way. It would be a loosing battle.
> 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.
Right. But the again, the Motif implementation has to obey the same rules
as you do. It seems to be happy with those rules.
> 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.
You can extend the AWT both through inheritance and composition. I don't
understand what your problem is.
> By providing such a limited interface to
> subclasses, you have effectively removed inheritance as an option.
I agree that some interfaces are a little restrictive but in general I
believe that this is the right thing to do.
> 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.
I can't remember what your examples are. I'm sorry to hear that you
unhappy with the AWT. I'm really pleased with it.
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
