Self ported to Linux

Jecel Assumpcao Jr jecel at merlintec.com
Wed Jan 23 19:51:08 UTC 2002


I guess this can still squeak by as not too off topic ;-)

On Tuesday 22 January 2002 17:30, Ted Wright wrote:
> Jecel Assumpcao Jr <jecel at merlintec.com> wrote:
> >No - you can simulate classes whenever you need them.
>
> That is one of the things I liked. I found it quite mind expanding to
> look at classes in this light.

One danger is that this flexibility could increase the typical newbie 
confusion between the "is-a-kind-of" and "has-as-part" relations. This 
is particularly true if they start new programs by copying the 
structure they see in existing applications (lots of empty "traits" 
objects right from the begining).

The solution I have found is a "lazy classification" development style 
as exemplified by the short tutorial in Demo.snap. You create each 
object as a stand alone entity and keep them that way until you 
absolutely need to refactor them into common elements in order to avoid 
a lot of duplication. Keep refactoring agressively (I doubt extreme 
programmers would complain about this...) until you end up with code 
that has as few class-like objects as possible. By not trying to 
anticipate the role of an object before you are actually working on it 
you reduce the chance of getting "is-a-kind-of"/"has-as-part" wrong.

Note that in eToys in Squeak you have the tools to use this development 
style. You can choose to use per instance properties and delay creating 
new classes until this approach becomes too awkward.

> John Maloney had one objection that was not obvious to me (probably
> because I'm just starting looking at Self and I'm not ready to think
> about how system tools would be built): "Since the object
> relationships used to build the Self equivalent of Smalltalk's class
> library are merely a matter of convention, system tools cannot rely
> on them. Programmers are free to write programs that don't follow the
> conventions. 

A Self programmer can make an object be a copy of a "myType" prototype 
object stored in "globals" and include in it a constant "parent*" slot 
pointing to an object called "traits myType". But he can also come up 
with something entirely different. So if you created a browser that 
depended on the "prototypes/traits in globals" convention your tools 
would break on many real applications.

> I think this is why, for example, Self has no
> equivalent to the Smalltalk's changes log and change set managers.
> These tools are much easier to write if you have the notion of
> "class" built into the language."

While David Ungar's "Transporter" application requires more manual care 
than I would like, it does not only roughly the same job as a change 
set manager but also much of the stuff planned for the upcoming 
packages system for Squeak. A primitive change log was added in Self 2 
and then removed in newer versions and the Transporter could be 
extended to handle this (I use the external Unix tool RCS instead).

Here is what is complicated by not having classes: imagine that you 
have an object A and you change some code in it and then make a copy of 
it (object B). How can you tell that apart from first copying A and 
then making the same change in both A and B? When you "file out" your 
changes, the actual text you generate might be rather different in each 
case. With classes you have a cannonical view of what is being changed 
(instances don't count). When all you have are instances, then there 
are several possible interpretations. But this isn't important - as 
long as you get the right objects in the end, who cares how they were 
built?

> > ["mixing of levels" in Self due to parent slots]
>
> I don't understand this issue (maybe I have not noticed any of these
> places in the "Demo.snap" image that is distributed with Self for
> Linux release).

See the various tree collections and check out how the #at:Put: and 
#deleteNode (among others) methods change the inheritance structure at 
runtime. All it takes as in innocent looking "... parent: ..." in the 
middle of your code. You can do the same thing in Squeak, but that 
requires going very deep in meta-programming land and by the time you 
find Behavior>>superclass: , Class>>addSubclass: and friends you have 
probably seen enough to make you come to your senses and turn back.

A lot of people get excited about this "dynamic inheritance" feature 
when they discover Self, but it probably isn't a good idea after all.

The other place where this "parent slots are like regular slots" thing 
makes the meta level poke through is in "directed resends", which are 
like "super" in Squeak. Since you can inherit from multiple parents, 
when you want to resend to one in particular you must explicitly name 
which one you are interested in.

-- Jecel



More information about the Squeak-dev mailing list