Pluggability

Sabine van Loon R.L.J.M.W.van.Loon at inter.nl.net
Thu May 28 21:35:19 UTC 1998


Tom you wrote:
[snip]
> This sounds similar to the stuff Digitalk did when they revised their
It is. Visual Smalltalk Enterprise is the successor to Smalltalk/V.

> Smalltalk system for Dos/Windoze.  My biggest problem with that was that
> their documentation and browser capabilities weren't upgraded along with
> the change, and I found it very difficult to make the change from the 
> early ST/V-dos methods, similar to current Squeak, to the new scheme. 
It is hard in the sense that it forces you to think differently about
objects.
Objects are not pulled for information anymore but can push information too
(via events). It really makes objects much easier to use. There is no need
for fixed protocols anymore and it easy to plug into existing
applications/objects.
I think a lot of people still associate events with a user interface but
that is not the case with the VSE event approach. Each object can trigger
an event, i.e. business objects, data objects, GUI objects etc. A
nice example is the event #dataAvailable which is triggered by a database
object when the results of a query are available. In response to that a
window could be opened. In fact, the whole event mechanism makes for a
loose coupling of objects and reflects much more the real world (i.e.
events lead to responses in the real world, events may affect multiple
objects at once and they allow asynchronous messaging).

> I hasten
> to add that I was working full time in C/C++, and trying to port my stuff
Done that for 5 years too. Was even busy writing a Dutch book on C++ in
that time until I realized that it was bad to teach other people C++.

> from ST/V-mac to the second version of it in my spare time -- and my
brain
> exhausts after a while -- playing a game becomes more attractive that
> trying to climb back on that learning curve...
Sounds familair. Most of the time the problems are processed in the
background while playing games.

> Hmmm... I have the glimmer of a project idea -- an ApplicationBrowser
that
> lets one browse the responses to various #changed: messages in an
> application...  Does such a browser already exist?    I recall adding (in
> ST/Vdos)  the ability to click on a window and open an inspector on the
> associated TopPane/View - which provides access to the Model, etc. 
> That's a start.... 
A list pane in VSE works like that. When a list pane is first shown (and
the list was not set yet), it triggers an event named #needsContents. If no
one responds to it, the list pane shows an empty list.
Whenever an item is selected in the list pane an event #changed: is
triggered. When an item is double clicked the event #doubleClicked: with
the item as argument is triggered. When the list pane needs the string for
an item it triggers the event #needsStringFor: with the item as argument.
So, lets put a Date and a Time instance into an array called theList and
suppose we have a list pane called theListPane. Then we can code the
following:

theListPane 
  when: #needsContents send: #setList: to: theListPane with: theList;
  when: #changed: send: #select: to: someModel;
  when: #doubleClicked: send: #inspect: to: someModel;
  when: #needsStringFor: send: #niceStringFor: to: someModel.

In this case someModel provides 3 methods: select:, inspect: and
niceStringFor: which could have been implemented like this:
Model>>inspect: anObject
  anObject inspect.

Model>>select: anObject
  selection := anObject

Model>>niceStringFor: anObject
  anObject isDate ifTrue: [ 
    ^anObject year asString , anObject month asString, anObject day
asString 
  ].
  ^anObject asString

I think Squeak Fabrik is a graphical way of specifying event->message
relationships between objects. Dolphin Smalltalk does the same in a method
called createSchematicWiring, i.e. create the wiring between objects. It
really is much more like hardware where a chip generates a signal on a
certain pin. The chip doesn't know/care if something is attached to that
pin. It just knows WHEN to generate the signal. The effect is defined by
the clients.

Hope this helps a bit.

I think this approach comes closer to Alan's Dynabook vision. I mean we are
still left with sequential processing although the original idea was not
like that at all (the real world isn't sequential or is it just that fast
that we don't notice it is sequential? ;-)

Groetjes, Reinier.





More information about the Squeak-dev mailing list