[1362] in java-interest
Re:Re: The need for "perform" in Java & instanc
daemon@ATHENA.MIT.EDU (Mike Christiansen)
Thu Aug 31 02:36:55 1995
To: java-interest@java.sun.com
From: mikec@metronet.com (Mike Christiansen)
Date: Sun, 30 Jul 1995 20:26:11 LOCAL
In article "John D. Mitchell" <johnm@emf2-003.emf.net> writes:
>Date: Wed, 30 Aug 1995 13:43:45 -0700
>From: "John D. Mitchell" <johnm@emf2-003.emf.net>
>To: mikec@metronet.com (Mike Christiansen)
>Cc: java-interest@java.sun.com
>Subject: The need for "perform" in Java & instanc
>> I see the need for smalltalk-like perform: and perform:with: operations.
>> These are needed to implement several useful patterns which are found in
>> ParcPlace Smalltalk and in the patterns book. For example, Adaptors map
>> the methods value and value: to class specific methods and are used to
>> map Views to Models in the MVC paradigm. ValueModel's are objects which
>> hold onto a "value" and provide methods value and value: as "getter" and
>> "setter" methods. Most of the Smalltalk widgets and other types of views
>> expect that the model they are presenting will respond to ValueModel
>> methods to provide a value to present. The Adaptor allows models which do
>> not support this protocol to be presented by such views.
>But is that last capability really necessary? If so, is it really
>necessary often enough to make the benefit of such heavy weight constructs
>as perform: and perform:with: outweigh their costs to the nice simple Java
>that we know and love? I don't know.
>A Java interface can be created for the 'ValueModel' protocol to allow for
>that part of the MVC paradigm. Any classes which need to be used in an MVC
>system implements that interface.
Well ValueModel was the simple example. But consider how VisualWorks manages
the layout and composition of the GUI windows the GUI builder creates. Each
GUI application maintains one or more "specs" which describe the layout of the
interface. These specs are literal arrays which are installed on class
variables. When an interface is created, the spec is parsed by itterating
through this array, and "performing" the symbols and values maintained by
the array. It is a very easy way to develop an information parser.
>> In fact this begs the larger question of how instance specific behavior
>> is to be implemented in Java. Each instance of an Adaptor is initialized
>> with its model object and the symbol names of the methods used to
>> accessthe model's value. Creating a new subclass of Adaptor for every
>> neededpurpose would cause hundreds of classes to be created.
>Have an "Adaptor" interface... That is, of course, a bassackwards approach
>compared to Smalltalk.
>I really love perform: & perform:with: in Smalltalk. They make for some
>slick code. However, IMHO, they don't fit the more 'static' model of Java.
>I not sure whether that's good or bad. Should Java become more dynamic
>(in this sort of manner)?
Yes, what you say may be correct. However, consider when a model provides more
than a single value which can be "viewed". e.g. an Employee has a name,
SSNumber, Sex, etc. If each of those values is to be displayed by a GUI
widget, each of those widgets expects its own model. ParcPlace provided the
ProtocolAdpator (I beleive the name is correct) which would be applied by
creating three instances assigned to the three aspects of a single Employee
instance. Each ProtocolAdaptor "instance" is initialized with the method names
of the accessor which it uses to get and set the value the GUI is viewing.
Each GUI Widget is associated with a ProtocolAdaptor instance. In turn, each
PA is initialized with the Employee instance and the names of the Employee
accessor methods which will access the needed value from the Employee e.g.
Employee>>name & Employee>>name:. Without this feature, the GUI Application
whould have to be initialized with the *three submodels* (breaking
encapsulation?) of the Employee, or some mechanism like the adaptor would be
needed to initialize the individual GUI widgets with the correct "aspect" of
the Empolyee model (not much different if you ask me).
Another useful feature of the Adaptors in Smalltalk is the "subjectChannel"
each one maintains. This is a ValueHolder which "holds" the model (the
Employee instance). Using dependence mechanisms between the ValueHolder and
the adpators, the application can replace one Employee instance with another,
and all three views of the employee model are automatically updated with the
values contained in the new model. Very slick.
Whew, that was long! Comments?
Mike.
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Facts are simple and facts are straight.
Facts are lazy and facts are late.
Facts all come with points of view.
Facts don't do what I want them to.
Facts just twist the truth around.
Facts are living turned inside out.
Facts are getting the best of them.
Facts are nothing on the face of things.
Talking Heads
Mike Christiansen
mikec@metronet.com
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
