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

Marko Mikulicic marko at seul.org
Sat Oct 28 22:31:05 UTC 2000


Hi,

Great to see you here, David.
I understand, now more than ever, that the Self language and ideology is

more complex than what it seems at first view.
One thing I really liked the first time I readed the progref was the
fact that methods were called "objects with code" and where, at least
teoretically,
regarded as objects. Nothing (some obscure "(2+3) is method" was a
little suspicious)
made me think that methods are in fact only meta-objects.
I writed an implementation of the Self language where methods are real
objects, wich
are evaluated when accessed through slots.
I really liked the slot initialization syntax and it was so natural and
beautiful:
( | slotname = <expression> |) wich handles data and methods
consistently.
 Once a friend asked me if in "1+(2+3)" "(2+3)" was a method. I told him
"no,
of course". He said it was written in progRef.
This story was a nonsense to me, because  if "(2+3)" was a method it had
to be evaluated
to take part in the expression, but then it has to be evaluated int "(|
slotname = (2+3) |)" too, but
"Evaluating a method does not simply return the object itself, [...], it
code its executed ...." (progRef p.5)
But the great unified syntax of slot initialization and expression was
so beatiful I mentally removed
the possibility of methods that executes itselfs when lexically present
in expressions.
 The thing that peplexed me more was that "1+ ( | a |  2 + 3 )" is no
more permitted.
Jacel explained what happened, but this is not an excuse. The current
way is completly inconsistent,
is a middle point, is chaos!

A brief recapitulation of the situation:
    Teorically, methods are objects, but are so handled that are
virtually uncachable (slot initializers can, because they are special,
but
doesn't appear so) because of autoevaluation. This means that all
subexpressions are methods, but ... not all methods can be
subexpressions.
Local variables in a method are implemented as slots but they, surprise,
cannot contain other methods.

If all this is because having "two type of slots" is unelegant I
disagree.
My idea is that "lexical presence" is different from "evaluation".
Having a method literal (object with code) does not implicate its
execution.
Accessing it through the slot is evaluation and does not implicate a
different container (slot) for data and methods.
  So, I don't really see the need of such meta-hinding of the methods.
A method will still do the same thing when you execute, whether is a
real object or not; this is not the point.
Manipulating method objects is not so important, what's important is
consistency and having a nice and
self-consistent way to create objects and initialize slots.
Modifyng methods was just my experiment and I'm not sure, I have just a
feeling, that it could be useful.
I made a mistake to express it in this thread.

> One of my goals for Self was to create a language that was as
> "object-oriented" as possible. That meant hewing as closely as
> possible to a model with only objects and messages, not bits and
> methods--just my particular perspective.

Your idea is good, but sometimes is not worth trying to do something "as
closely as possible".
It's better to do it until the end, or not do it at all. Or, at least,
do it but be aware of what you got, and what you wanted to.
If you want to respond to the messages you will need some kinds of
methods. Whether these methods are real, meta or whatever,
you will need them. I think that is more "object-oriented" having
methods that are objects than having methods that are meta-objects,
since
you must have them. I would very interesting finding a way to eliminate
code as different entity and merge the "object model" with
the behaviour (like lisp). But I think that having real method obejcts
is also a step forward in you vision

Please don't take it as flames for you and other Self  developers, you
really did a great job, but this is my point of view;
it's a shame leave this inconsistency when, IMHO, it will not make lots
of  incompatiblities.

I'm very interested in your opinion and the opinion of everyone in this
list.
Excuse me for the kilobytes invested in this post, hope you had the
nervs to read it all :-)


Marko

---------
www.openself.org




More information about the Self-interest mailing list