[self-interest] Re: simple object model

[Jecel Assumpcao Jr]

On Friday 06 April 2001 13:25, Uladzimir Liashkevich wrote:

> >              ... ^ ( (| x. y |) x: sX) y: sY
>
> It looks much better.
> Idea! Not I know what I actually wanted:
>   prototypes point copyWith: (x 3 y 4)
> I.e. initializing an object with a hash.
> The copyWith: method can be easily implemented in Self, but it misses
> literal hashes (more importantly, initialized at run-time).

Like I said to Steve, I don't really see any difference between current 
Self objects and hash tables. You could implement the 'copyWith:' 
method so that you can write

    prototypes point copyWith: (| x=3. y=4 |)

If you wanted sX and sY instead of 3 and 4, then you would need a 
complex unquoting notation like some languages have. Though Self has 
literal objects (like in the above example), it lacks a syntax for 
literal arrays and other things. The closest we have is the use of 
runtime expressions:

             ( 1 & 1 & 2 & 3 & 5 & 8 & 13 & 21 ) asVector

instead of:

            #( 1 1 2 3 5 8 13 21 )

But since it is an expression that builds the object at runtime, you 
can replace the numbers above by any expression in Self but it becomes 
complicated in Smalltalk.

Rebol has a rich set of literal object syntaxes, but I think this is 
something that only makes sense in a purely text based languages. As 
our programming environment becomes more and more graphical, I would 
rather create my literal objects with some proper tool and just drop it 
in the middle of my code. After all, though I can't show this in an 
ASCII email (but could do so in a HTML one), it would be nicer to see

                 currentCursor: <image of hourglass>

than

                currentCursor:
'1000000000
1100000000
1110000000
1111000000
1010100000
1001010000
0000100000
0000010000
0000001000' newCursorFromString                                       

That is also my opinion about Scheme-like macros. Penny wise, pound 
foolish. They are trying to make more readable things we shouldn't have 
to read.

> > [do we actually gain anything by making
> > parents visible at the base level?]
>
> For example, hierarchies of traits/prototypes.
> Also for eliminating ambiguities:
>   globals app1 myObject
>   globals app2 myObject

These are regular data slots, not parent slots. About 
traits/prototypes, you do have a point in that we get to reuse the slot 
initializer syntax for setting the inheritance relationships. But that 
is not important in a GUI environment, only a pure text one.

> At first glance I liked the idea of declaring maps, but now I see
> some drawbacks here. The main is that the notation is
> position-dependant, i.e. if later you want to add another slot to the
> map - (x : x1 : y :), you should carefully keep track of positions in
> the list of slot initializers - ((x : x1 : y :) 3 10 4). But what if
> the number of slots is very high?
> IMHO, it is an error-prone construction.

There are plenty of problems with this idea. But you wouldn't have to 
manipulate objects at this level directly - there should be graphical 
tools to take care of the details and get things right.

> In my implementations I have a hidden object with all primitive
> slots. When a message name begins with underscore then a lookup is
> performed in the hidden object.

My problem with this is that it isn't very object oriented. If you do

               someObj _PrimXWith: n

then '_PrimXWith:' is actually a global function (with someObj and n as 
arguments) and not and method. So much so that if someObj is not what 
the primitive was expecting you get an "invalid receiver type" error 
and not a "does not understand" error.

Of course, you can think of your hidden object as representing the 
virtual machine. It is just that I don't like one giant object doing 
everything by itself.

-- Jecel