Method are not objects?

[3prometheus at home.com]

--- In self-interest at egroups.com, Jecel Assumpcao Jr <jecel at m...> 
wrote:
> Self defines that any reference to a method object causes its 
execution
> directly. This allows you to send 'm' to your second object and get
> 'ciao' as the answer instead of the method object itself. The 
problem
> with this is that you can then never reference any method directly, 
but
> only through a mirror object.
> 
> The alternative would be to allow methods to be referenced and 
stored
> in slots like any normal object, but have a special type of "auto
> evaluate" slots where you could store methods and have them behave 
the
> way they do now in regular constant slots.
> 
> Self's designers simply felt that the "special slots" solution was
> uglier.

IOW, mirrors are not slots. This is just what I needed (confirmation
that they had, IMO, made an error).

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


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.

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.

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.

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