Re(2): ambiguous inheritance question
Jecel Mattos de Assumpcao Jr.
jecel at lsi.usp.br
Wed Feb 8 04:32:26 UTC 1995
On 1 Feb 1995 18:04:48 -0800 "David Ungar" <david.ungar at Sun.COM> wrote:
> By the way, I'm intrigued by a different style of programming,
> but unfortuneatly our VM doesn't quite support it efficiently enough
> to convert over the whole system.
It is a good idea to think about these thing anyway. They might end up
in other people's languaged even if they don't fit Self to well.
> In this style you lump together methods and data slots,
> and use data parents (with single inheritance!) instead of copy-down.
> so a point has:
> parent, +, x, y in it.
> and a colored point has
> parent* <- aPoint
> color <- ...
> <other methods>
> in it.
This looks very interesting. But...
1) What does clone mean here?
I would guess that you would have to "deep" clone the object
and all of its data parents. Would this be right? We can do
this today by adding these slots to traits clonable:
dataParent = ().
clone = ( _Clone dataParent: dataParent clone ).
dataParent: obj = ( ^ self ).
There are bugs in this, but you get the idea. Any object with
and assignable slot called dataParent would automatically clone
it whenever itself was cloned. This stops at the first "normal"
2) Do we want to get rid of traits?
Maybe. Traits make things more complicated and less concrete, but
they are used for:
A) Saving space. This is not true in any practical implementation
of Self. In fact, dividing an object into prototype and traits
makes it about 11 words larger ( though all of this overhead is
shared with all of its clones ).
B) Changing shared behaviour. If you change a method in a point, no
other points are affected. When I programmed my CMOS simulator
in Self 1.0 this didn't bother me and I wrote a lot of methods
in the objects themselves rather than in traits. That is because
I would throw away all objects and clone them all over when
re-reading a Self script. Traits allow you to change an
application while it is running ( or being debugged ), just
like Smalltalk does. On the other hand, no system allows you
to change the format of the objects without first getting rid
of all instances.
C) Naming a useful concept. Separating prototypes from traits
allows you to inherit abstract interfaces without also
3) Can we get by without multiple inheritance?
Actually, though I agree getting rid of parent priorities and
default conflict resolution was the right choice, it is now
harder to use multiple inheritance for anything other than
mixins. We don't need MI to get around a type system like C++
does, so I don't know how much I would miss it if we didn't
have it at all. But I hate having to chose whether a string
is a collection or a magnitude.
> The catch is that the parent slot of colored point
> causes a bunch of inefficiency today, otherwise
> I would be doing it in a big way.
I have to admit that this is much more my style too.
> But there are ways to make this work well (
> one was suggested by Craig a long time ago and I haven't
I don't see much of a problem here. Just inline all of the
data parent methods as if it were a constant parent. When
you send parent:, just check if the new parent has the
same map as the old. In the rare ( if this were the normal
style, of course, not currently ) case where it is not you
have to recompile stuff to look more like it does today.
> I really think it would be better than what we have.
I am not sure, but I will always vote for simplicity.
> Maybe for Self 5.0, if and when....
I don't know what is happening over there ( some rumors in
comp.lang.smalltalk, though ), but you can be sure it is
a case of "when". The good new is that there *will be* a
Self 5.0. The bad news is that it will be called VisualBasic 7.0 ;-)
More information about the Self-interest