[self-interest] Two simple Self questions and one Self design philosophy query

[Jecel Assumpcao Jr]

On Wednesday 16 June 2004 18:44, Michael Latta wrote:
> Initialization expressions (like traits clonable) are by definition
> evaluated in the context of "lobby" which does know what traits
> means. Your example also shows why this rule is there rather than
> evaluating the expression in the context of the new object (which is
> stone dumb at that point).

Exactly. This also means that you can't use an objects own slots in 
initialization expressions, like

  ( |  x = 9.  z <- x + 3 ...

since "x + 3" would be evaluated in the context of "lobby" and not of 
the partially parsed object.

This made sense when Self was a purely textual language and programs 
were created as simple ASCII files, but is not an idea I would like to 
see in future implementations.

> On Jun 16, 2004, at 11:59 AM, Ben Moseley wrote:
> > The first simple question is - suppose I have an object
> > representing a table which has four slots to  four other objects
> > representing its legs. If I send a "copy" message to this I will by
> > default get a new table which shares the legs of the old one (ie -
> > it is a shallow copy). What is the standard Self idiom for
> > achieving the desired affect? Is it to implement a custom "copy"
> > method?

Normally "clone" is always a shallow copy while "copy" is a custom 
method which defines the proper semantics for copying the specific 
object (in this case, also copying the legs).

> > Finally, Self makes a clear distinction between prototypes which
> > are copied (but not inherited from) and traits objects which can be
> > used for inheritance whereas some other prototype languages merge
> > the two concepts (ie they inherit via their prototypes by default).
> > I know one of the original reasons given for the Self approach was
> > to ensure that the prototype object was genuinely a prototype of
> > objects cloned from it and not special in any way, but I am curious
> > if with hindsight this is viewed to be a strength or a weakness of
> > Self. (If this has been discussed elsewhere I'd be very grateful
> > for pointers).

Note that you can organize a Self program by making new empty objects 
inheriting from their prototypes and possibly growing after that. This 
would be very slow, however, since it is not the style for which the 
virtual machine has been optimized. But the language itself doesn't 
exclude this (it doesn't help either, since copy-on-write slots are 
awkward due to a lack of explicit support for them).

The main problem with the Io or NewtonScript model of prototype based 
languages is that objects change a lot during runtime and you get many 
slightly different ones. This has performance issues (doesn't hurt very 
simple implementations but makes optimizing very hard) and can also be 
confusing for the programmers.

These two papers are about organizing objects in Self but don't 
explicitly mention the style you are asking about or why it wasn't 
adopted:

http://research.sun.com/self/papers/organizing-programs.html

http://research.sun.com/self/papers/parents-shared-parts.html

If you think of Self as a dialect of Smalltalk instead of an entirely 
separate language, some of the design decisions might make more sense.

-- Jecel