parents (was: Simpler Self RFC)
Jecel Assumpcao Jr
jecel at merlintec.com
Fri Aug 9 22:36:35 UTC 2002
On Friday 09 August 2002 00:02, Josh Flowers wrote:
> > [...] Parent slots were Alan Kay's main objection to Self
> > and that got me thinking about them.
> Did he have any specific objections to parent slots?
Yes - that they expose meta-level stuff (the inheritance structure of
the program) to base-level programming. See section 4.1 "Behaviorism
versus Reflection" of the Self 4.0 Reference Manual for a great
explanation of what is wrong with that. It ends by saying
"In short, to maximisze the opportunities for code resuse, the
- avoid reflection when possible
- avoid depending on object identity except as a hint, and
- use mirrors to make reflection explicit when it is necessary"
Of course, Smalltalk is even worse since an innocent looking "class"
message can lead to horrors such as
obj class == Point ifTrue: [....]
And what are parent slots compared to this? But the issue is that parent
slots are a "pun", which are fun for the language designers but not
always a good idea. By combining the idea of constant (or data) slot
with the idea of a pointer to an object to delegate message to we
- no need for a special syntax (other than a "*" at the end of the
slot name) for decribing the inheritance structure. Note that this was
more important when Self was a pure text language than it is now.
- the ability to change parents at runtime with simple message sends
and also to know for which parents this could be done or not (it
depends if a parent slot is a data slot or a constant slot). Since we
don't have a good implementation for this it hasn't been used much.
> I find them a bit odd myself, but I think it's more because they're
> named 'parent slots' then because of how they're implemented. Unlike
> parents in a class based language they cannot contain data that
> should be shared between their children, only behavior.
Actually, they can contain shared data (class and pool variables in
Smalltalk terms) but they can't define a "shape" for their children.
That is, it can't say that all its children should have an "a" and a
"b" data slots like a class can in Smalltalk.
Note that this is a limitation of the programming language, but the
programming environment gives us a solution in the form of "copy down
slots". These are shown in pink instead of gray and are copied down to
all the children when these are created.
> This makes
> their usage feel strange when your more accustomed to a classic OO
> language. I'm not sure Self's inheritence is a bad thing (I know
> it's been stated that inheritance is actually harmfull because it
> breaks encapsulation), but it does seem odd at first.
We used to have slot privacy declarations back in Self 1.0 and 2.0 but
you could get around these by dynamically inheriting from an object you
wanted to "see the inside of". Now all slots are public so we don't
have much encapsulation in the first place.
> Maybe name them behaviour slots, or delegate slots (although they do
> more then just delegate messages)? It also seems like there are a
> couple of different uses for these special slots -
> 1) simple message forwarding - your simply sending the message to
> another object i.e a parent reference to globals.
> 2) behavior sharing - not only do you need to forward the message to
> another object, but that object needs to reference the object that is
> forwarding the message (as 'self' none the less).
Having only #2 is enough since who is "self" doesn't matter for #1.
> 3) inheritance - everything that #2 does, plus copying the "child"
> object must also cause the parent to be copied. As far as I know
> this doesn't exist in Self, but I haven't looked into it.
Not in the programming language itself.
> Of course I haven't used Self that much, and these comments are
> somewhat off the cuff, so I may be speaking in error.
In my proposal I wanted to leave parent objects exactly as they are now,
but they wouldn't be pointed to by special slots. Instead, you would
have to use an explicit mirror if you ever needed to access them
(advice 3 from the Self Reference Manual).
More information about the Self-interest