simple object model (was: [self-interest] selfing Self)

[Jecel Assumpcao Jr]

I am sending a copy of this to the self-interest list. I hope you don't 
mind.

On Friday 30 March 2001 04:39, Uladzimir Liashkevich wrote:
> Let me join the discussion. This is a very interesting topic to me.
> When I first read about Smalltalk I thought that it is the greatest
> language ever. Then I discovered some difficulties with the language,
> for example absense of multiple inharitance causes strange
> inharitance trees like Object -> ReadStream -> ReadWriteStream.

My favorite example is String, which can't decide if it should be a 
Magnitude or a Collection...

> When I read about Self, I felt the same as in the case of Smalltalk.
> Later I discovered the absense of some needful possibilities. One of
> them is constructing objects on the fly. One cannot write something
> like this: (| x:Y: = (| :aX. :aY | ^(| x <- aX. y <- aY |) ) |).

While this doesn't work because slot initializers ("aX" and "aY" in 
this case) are always evaluated in the context of the lobby object, you 
can get the same results with:

     (| x:Y: = (| :aX. :aY. new |
            new: (| x. y. parent* = traits clonable |) copy.
            new x: aX.
            new y: aY.
            new)
     |)

The reason I used 'copy' above is that I am supposing that you don't 
want successive calls to this method to always return the exact same 
object, but just the same kind of object. If that is the case but you 
don't want the new object to be clonable, we could use the '_Clone' 
primitive instead of 'copy' and eliminate 'parent*'.

If you wanted 'x' and 'y' to be constant slots in the new object (you 
didn't show that in your example) then things do get much more 
complicated. It is still possible to do this using mirrors, however.

But I was indeed trying to make this kind of thing simpler.

> So
> now I'm in process of thinking out a more flexible but yet powerful
> language. By now I have implemented two experimental versions of
> Self. But I need something different.

Me too, but more in the spirit of Self than the Self-inspired languages 
of the early 1990s.

> > Like a simple object model: objects are just flat association lists
> > (I'll use Lisp notation below) -
> >
> >        (x 3 y 4)
>
> flat list has an array structure rather than linked list?

By "flat" I meant compared to this form of association list:

  ((x 3) (y 4))

But it is a *very* interesting question if these should be arrays or 
linked lists -

  Lists: + can be shared as the continuation (CDR) of several other     
               lists
            + can be scanned using a single pointer
            - since you can point into the "middle" of a list there are 
                many aliasing problems
            - can't be indexed into
            + can be as space efficient as arrays with special encoding
            + easy to split and put together

   Arrays: - need three items for scanning: base, index and size
                + no need to waste more than one virtual address per    
                   array
                + access to any element is equally fast

It is easy to convert one into the other when you need to do some kind 
of processing for which the normal format is not very good.

> Do you want to use the same semantics for a objects, arrays and
> hashes? Like, (1 2 3) - array, (x 3 y 4) - object or hash?
> Please describe that semantics a bit more.

Every object is a list, but there are lists which are not formatted 
objects (the code examples below, for instance). So I must treat (1 2 
3) as an object which does not explicitly list the messages it 
understands. In fact, the object "1" has this problem as well, but at 
least the number objects have special tags so they don't look like they 
might be a regular object. I am still figuring this out.

> >     append '(z 9) '(x 3 y 4)
>
> Is this a message-sending construction? What is the receiver?

No, this was a pseudo Lisp functional notation. This would be more 
proper

   '(z 9) append: '(x 3 y 4)

though the problem above shows itself here: how does the '(z 9) object 
understand the 'append:' message? We would have to force it to be 
treated as a plain list, which is getting into the reflective level and 
similar to requesting a mirror for an object in Self.

This needs some careful design.

> How to distinguish objects and methods?

I am thinking of making methods internally be objects that have a 
special <code> "slot"

 ... factorial: (n 0
                     <code> (n < 1 ifTrue:False: 1 '(n * factorial: n-1)
                                   )
                    ) ....

I have other ideas for blocks than quoted lists, but this will do for 
now. Hmmm... if instead of "<code>" I used "|" then this would look 
more like Smalltalk...

Note that though the argument "n" has a default value of 0, it will be 
replaced once this code object is cloned to create a context object.

> Did you get rid off keyworded selectors like a:B:C:?

I used one in the above example, but at the low level the keywords 
aren't spread among the arguments. In a higher level graphical editor I 
would expect you to be able to write something like

    n < 1 ifTrue: 1 False: [n * factorial: n - 1]

My idea is that the arguments would be underlined, but that is hard to 
show using ASCII in this email.

> > [these nested lists can act as both "maps" and parents]
>
> Really good fresh idea.
> It seems that all slots are assignable, doesn't it?

That is something to be fixed. The implemenation must be able to tell 
what is changable and what is (normally, at least) constant. In the 
NeoLogo implemenation where these ideas came from you could write

  make "x 10

and simply change the value of the x "slot". It would be better to do 
the same thing by sending a message instead

  x: 10

and you could have the Self rule that unless there is a "x:" method 
then "x" is a constant slot. I don't know what the best way to handle 
assignments is. I have always felt that assignments and argument 
replacement should be somehow related. Kyle doesn't like the fact that 
assignment slots must be in the same objects as their data slots in 
Self (they can't be moved into the parent objects, for example).

> The first challenge is to invent such system, then it can be
> optimized. Remember that many people doubted that Self can be
> implemented efficiently...

Right, we can always hope that history will repeat itself. On the other 
hand, there are many examples of interesting ideas that nobody ever 
figured out how to do reasonably well. Dynamic parent slots in Self are 
an example (actually, I did figure out a way to do it but haven't tried 
it yet).

-- Jecel