[self-interest] patterns and Self

[Jecel Assumpcao Jr]

On Thu, 14 Dec 2000, Thomas Kuehne wrote:
> I would not argue that Self and Smalltalk *need* the internal
> version of the Iterator pattern because of their awkward syntax for
> accessing vector elements.
>
> Rather, the Smalltalk languages/library (can not speak for Self
> really because I do not know its approach) got it right in terms of
> releasing the iteration clients from the burden of providing a control
> structure (i.e., loop) each time they want to enumerate the elements
> in a structure. In other words, even languages with a fantastic syntax
> for accessing vector elements should not be doing the external
> iteration style. AFAICS, there is no good reason to do external
> iteration (see my paper "Internal Iteration Externalized" if in doubt
> :). 

Exactly - APL has the best indexing syntax of all of the languages I
know and yet it is very rarely used because the iterators (actually
invisible, but still there) were done *right*.

You have a very good point, I didn't express myself very well. I should
have said that Smalltalk/Self handle this pattern so well that they
have no need for a better indexing syntax (which is a common newbie
request).

> Probably the Mediator pattern realization as described does not
> benefit from Self's capabilities, but maybe an enhanced version would,
> where Mediator methods could work in the context of the objects the
> Mediator is controlling. That way mediating code could be completely
> concentrated in the Mediator and controlled objects would never need
> to know about mediators.
>
> > ===> Observer(293):
> Same argument here. Maybe an implementation that better separates
> concerns could be realized with Self's delegation features. Getting
> the right piece of information after a change from the Subject to the
> Observer maybe is easier with delegation?

I am not sure how you could structure things to use delegation in these
two patterns. It would be nice if they could be made more transparent
for the objects involved.

But after I had sent the previous message I did think of a Self feature
that makes implementing these patterns simpler. If you have an object
that was originally created to work by itself, and now you have to
adapt it to report state changes to a mediator or an observer, it is
very nice that Self makes no distinction between data and method slots.
So we can take data that used to be stored in a slot called "color" and
move it to a slot called "rawColor" while adding new "color" and
"color:" methods that both change state and do the necessary reporting.
All other code works as before. In most other languages such a change
would involve substantial code rewrite. It was silly of me to say there
were no examples of these patterns with all those "raw" slots around.

In another email, Albertina Lourenci asked about the Abstract Factory
pattern and platform independence.

Note that Self applications run and look the same on a Sparc, a Mac or
in any future implementations of the language. And that is possible
thanks to the use of the Bridge pattern in the canvas part of the
graphical user interface. The applications always see the exact same
drawing capabilities, no matter what the actual platform can do.

-- Jecel