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

[Richard]

Jecel Assumpcao Jr wrote:
> 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.

Yes. I'd read about mirrors but it was in a different context (ie, maps)
and I never made the connection. ;-)

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

Is it? Then it isn't possible to have write slots for methods?

It seems to me that accessing methods has to be on the same level as
writing methods and because of consistency over the unified read data/
eval method concept in Self, you should have writing methods at the
same level as writing data. But then, I would disagree that _Define
and _Migrate belong on the same level of abstraction; the ability to
create new slots should not be invisible to programmers the way that
clone families should be.

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

Of course. But time and again, I insist that a facility be present purely
for symmetry and elegence. It need not be used often or implemented in
the same way, or even at all efficient, so long as it is present. Even
if runtime creation of methods is rarely used, I believe it should be
there.

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

Take it up with Self's designers since they're the ones responsible for
unification of data access and method evaluation. And they, rightly,
decided that "how it's done" is completely irrelevant. The result of
data accesses and method evaluations do look the same to me.

If a slot contains data then upon 'reading' the slot returns itself.
If a slot contains a method object then upon 'reading' the slot, it
does what you say. I am claimmng that there should be a slot which
returns an associated slot's method object (raw, as it were) and,
just as asymmetrically, decompiles the data slot. In both cases, the
slots return the same thing (either what looks like the result of
evaluating an expression or a method object) and whether it's a
data slot or method slot changes only the local storage of what's
in the slot, not what you can do with it.

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

<Grin> You've answered your own question. Just like write slots end
in a semicolon, decompile & "read method" slots (eval slots being the
normal "read data" slots) might end with another special character.
Perhaps, to reverse ML, it should be the exclamation mark.

> And note that you can have a read slot without the
> corresponding write slot - that is how you indicate constants in the
> language.

Yes, but that may be a mistake. After all, x: is still a special
slot (specially connected to x) regardless of whether it exists
or not. I think that either any slot must be able to write to
any other slot, or that slots should /explicitly/ (instead of
only implicitly) come in pairs/triples. The way it is now, Self
expresses public/private by the existence or non-existence of
the associated write slots. Isn't public/private being dropped
from Self because it is redundant? I don't mind the absence of
a write slot denoting a constant but what does the absence of
a read slot (and the presence of a write slot) denote?

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

Which is probably why I don't plan to ever implement symbolic links,
which are a horrible kludge in any case. (Yes, that is precisely what
I was talking about :-)

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

Thank you.