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

[Michael Latta]

I can see wanting to reference the slots of the object under 
construction, but it would also need to reference the
environment.  Maybe the object under construction should have an 
implicit slot to lobby that is removed after compilation?

Michael


On Jun 16, 2004, at 5:09 PM, Jecel Assumpcao Jr wrote:

> 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
>
>
>
> Yahoo! Groups Links
>
>
>
>
>