[self-interest] Re: Method are not objects?

[Jecel Assumpcao Jr]

On Sat, 21 Oct 2000, 3prometheus wrote:
> IOW, mirrors are not slots. This is just what I needed (confirmation
> that they had, IMO, made an error).

Mirrors are indirect references to objects, which allow you to do
things you can't to to the objects themselves. They are "meta-objects".
They are not slots, but they can appear to be a collection of slots.

> I am new to Self and I hope people will indulge me by considering a 
> few (doubtless already well-known) observations I have made.
> 
> Self's designers admit that their write slots are inelegant and I have
> been thinking about the problem in an abstract sense. The way I see it
> is that there are 5 fundamental abstractions;
> 
> accessing data, writing data
> accessing methods, writing methods, evaluating methods

Note that "writing methods" (and possibly "accessing methods" as well)
is at a different level than the other operations, unless you want a
Lisp-like runtime creation of methods. Otherwise, writing a method is
something the programmer does before the code is run while the others
are things that happen while the code is running as a result of message
sends.

Of course, the software that allows you to write and edit methods is
itself written in Self and works through message sends too. But it is
nearly always changing other code, not itself. While this distinction
might not matter from a language design viewpoint, it is only by
designing the system around the idea that methods very rarely change
while running that Self can perform as well as it does.

> If one wishes to unify data and methods, then one has to figure
> out what evaluating data means. If one unifies accessing data with
> accessing methods then one is forced to have evaluation of data be
> the same as accessing of data. This is ugly and Self's designers
> were very wise to not unify the abstractions this way. Instead,
> they unified accessing of data with evaluation of methods. This
> leaves open of what accessing of methods is to be unified with on
> the data side. The answer is a method, created at runtime, that
> evaluates to the value of the data. It's simple and consistent.

I am not sure I understood your various unifications, here. Note that
when you evaluate a method, a clone of it is created and it is this
clone that is executed (otherwise you couldn't have re-entrant methods
since different executions would mess up the argument and local data
slots). That seems very different from data accessing to me.

> One solution that was proposed to fix the inelegance of write
> slots is to have slots come only in assignment/storage pairs.
> It seems that this must be extended to read/write/eval triples.

Read and write slots have different names. How would you distinguish
your eval slots? And note that you can have a read slot without the
corresponding write slot - that is how you indicate constants in the
language.

> Whether anyone creates a language on this basis (and if they do,
> might they consider allowing the use of variables as standins for
> method names in a natural way?) this observation has already proved
> invaluable to one of my pet projects. In a filesystem, it doesn't
> make sense to allow people to access methods' source code (because
> it just doesn't change that much) but it must be possible to make
> the distinction between the link to a node and the node itself.
> Reading and evaluating makes this distinction.

Are you talking about "links" like in most Unix file systems? There is
a strong analogy between these and the "auto evaluate" nature of method
objects. But most file systems aren't very consistent in how they
handle this: try "ls x" and "ls -l x" where x is first a normal
directory and then a symbolic link to that same directory.

> And if I didn't love design so much I might be angry at Self for 
> forcing me to turn my design inside out just when I'd finalized it!
> Of course, it's a lot more elegant and OO now <wide grin> ....

Good luck,
-- Jecel