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

Marko Mikulicic marko at seul.org
Thu Oct 26 16:01:31 UTC 2000


Richard wrote:

> Marko Mikulicic wrote:
> >     1. If methods are so "volatile", they cannot be taken in hand, touched,
> > handled, from where did all these method come from? answer: with slot
> > initialization. The slot initialization syntax is then something different,
> > special. The mirrors are something extern to the language and can be useful
> > to handle, for example, names of slots in a debugger, but not something so
> > essential as methods.
>
> I think you make a very good point. Until now, I had set aside my unease
> with initialization syntax; I don't think I'll be doing this anymore. :-)
>
> > a:B::: for "a:B:"
> > Appending a double colon "::" says "don't evaluate".
>
> I don't know if I agree with this syntax because I'd think of a:: as
> a two parameter method. I think a different symbol should be used in
> order to distinguish the two operations (perhaps the exclamation mark?).

"a::" is not a two parameter method, because every argument in a keyworded
message
send must have it's associated keyword (capitalized): "a:B:".
I think the "a: arg1 : arg2" sytax would be very confusing and non-productive. It
could
be only useful when converting other languages wich uses prefix-syntax (Java)
into Self-Smalltalk,
but then it could be "a: arg1 A2: arg2 A3: arg3 ...." as a convention.
 Using another symbol  reduces the elegance of the language and breaks
compatibility.
Self has the fewest possible reserved symbols, and ":" is used for message
passing.
"::" could be seen as a message to the slot itself and not to the object
contained in the slot.

>
>
> Does Self have special syntax in x: slots to indicate assignment of a
> value to the x slot, or is it automatic that if a slot x exists then
> x: /will/ assign its parameter to the slot x? (You know, I'd completely
> forgotten that x: could just be a one-parameter method.) If it's the
> latter then it doesn't make sense to ask for the method associated with
> that slot. OTOH, if special syntax is used in x: slots then the same
> scheme should be used in x! slots.

There is no special syntax for assigning.
Slots that are defined as read-write are in fact two slots:
"a" and "a:", the latter containing an "assignement primitive"
wich could be regarded as a primitive method wich assigns the argument to the "a"
slot.
Asking for a method associated with a slot does make sense!
In Self4 it is done with mirrors, but I think that it would be nice if a minimal
syntax improvement
would allow accessing of methods within the language itself, without runtime
extensions (mirrors, _primitives, ...).
The language would be more complete

> > (| mymethod =  (| a <- 4| a print. (mymethod:: a: a-1 a) = 0 ifFalse:
> > [mymethod])
> > wich would print "4321"
> >
> > This is only an idea. What do you think?
>
> I have to say that if the above is the only use for allowing references
> to slots, then junk it. :-/

No, it's the only example wich I could write in one line.
I think it can come handy in many different situations. It can be put near the
dynamic inheritance.
It allows more dynamic code behaviour. Imagine that you have to use mirrors or
some external feature to
change a parent in Self, instead of using a read-write slot...
In addition the direct slot reference would be used instead of mirrors in many
situations.

But I think the major point in this extended syntax is for making self a
self-consistent language.
But, again, it's just an idea. I think the most important thing is rationalising
the slot initialization
and the question whether a method is a real object or just a bad actor.


Marko





More information about the Self-interest mailing list