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

Marko Mikulicic marko at seul.org
Fri Oct 27 12:50:39 UTC 2000


Richard wrote:

> Jecel Assumpcao Jr wrote:
> > So while I can't write to the doOp method slot (at least not with
> > normal message sends. We can change it with primitives or mirrors) I
> > can change the mom slot to switch doOp between a few pre-written
> > methods.
>
> Well, that is wildly inconsistent. "one way" unification is not unification.
> If instance variables are unified with methods then they should have the
> same abilities.
>
> > The only "runtime creation of method" that makes sense in Self is to
> > have the user type in some text and use that as the body for a new
> > method. This is not at the same level as what you can do with Lisp or
> > Logo (where you can get some code, transform it in various ways and
> > then run it).
>
> And why doesn't that make sense in Self?

Same question.
In self we won't mix around operands and operators in the code (althrough we
could
mix around bytecodes, but that's another story). Thats because the code in Self
doesn't have
the same shape as data, as it happens in Lisp. But then why don't let access a
method as a real object (the main phylosophy
of Self is that every thing is an object, a method too) and allow to change its
slots (not it's code) the
same way it's done with other objects. Changing the code is another question.

>
>
> > Which brings me to an important point - neither you nor Richard have
> > said anything about blocks. They are a major complication in the
> > language and have everything to do with methods automatically
> > evaluating themselves whenever they are referenced instead of just when
> > you want them to.
> >
> > An improved Self (read: simpler!) should somehow unify blocks and
> > non-autoevaluate methods.
>
> You're right. The x! slot could return a block instead of a method.
> Actually, I don't know why blocks and methods aren't unified ... ?

I was intrigued by the possibility to merge blocks and methods in the same
entity.
I imagined that a block object, instead of containing a value slot containg a
method,
would BE a method containing a parent slot pointing to a block traits (because
blocks must have
some behaviour, for looping etc). But imagine you have a block argument that is
named "value" or "someMethodContainedInTheEnclosingMethod". This slots would
screen, either calls to the block and calls from the
block out.
 I think changing the way block behave could lead not to dialectization of the
language (like this one on "method true objects")
but an entierly new language. I would be nice if we find some way to unify
methods and blocks but retaining quite unchanged the features of
the block. The basic idea is that a block is an object that responds to a
"value" message. This is important because instead of it, any object
wich responds to value returning itself could be replaced. Having a true method
object  with a slot called "value" pointing to itself, and a "block traits",
and autoevaluation disabled, one could implent a block but then all the
problems about the "two kind of slots", one wich evaluates and one wich reads
raw is back.

I'm more concerned at this moment with the unambiguity of slot initialization.

(| a = 1|)   and (| a = (1) |)

are completly different. This is because (1) is regarded as a method.
in 1+(2+3)    "(2+3)" is not regarded as a method anymore, in the
implementation, but in theory could be a method
since the expression above is equivalent to 1+(|| 2+3).
But since 1+(|a| 2+3) is no more legal and, as Jacel said, the parser optimizes
out the submethod as a subexpression I think
it's very confusing to the user and very inconsistent to have the method
autoinvocation and  to consider
1.   (1) a method. It should be (||1)
2.   () an object, although it nice and handy, it should be (||)

I think that this little change could improve the consistency of the language
and give back a real body to methods
wich were as ghosts in a world populated by real objects :-)

About the accessing of methods... I think this is a separate issue wich is a,
IMHO, a battle between simplicity and power in wich
is not always easy to get a good compromise.

Marko




More information about the Self-interest mailing list