Re(2): ambiguous inheritance question

[jecel@lsi.usp.br (Jecel Mattos de Assumpcao Jr.)]

On 1 Feb 1995 18:04:48 -0800 "David Ungar" <david.ungar@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"
   object.

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
      inheriting implementation.

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
> forgotten).

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 ;-)

-- Jecel