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

Richard 3prometheus at home.com
Thu Oct 26 21:34:04 UTC 2000

Marko Mikulicic wrote:
> Richard wrote:
> > 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.

I still don't agree with the syntax. It doesn't matter that a:: is not
a useful/valid selector, it can still be thought of as a selector even
in Smalltalk. And if you're going to start addressing slots then you're
opening a huge can of worms; I have nothing against it as long as you
allow other meaningful messages that you can send to slots (like, the
time when they were last accessed or modified, or the permissions on the
slot, which may be too expensive in the general case but are necessary
for a modern secure OS).

Much more important, you are treating "method containing slots" *very*
differently from "data containing slots". After all, the "no evaluate"
syntax for an assignable slot x would be x:, but that's already taken.

So far, you're merely reimplementing mirror functionality using different
syntax and that just gets you a net increase in complexity in the language
(admittedly for a net decrease in complexity in users' code). It seems to
me that you are thinking in terms of autoevaluate versus return of methods
but that's just an implementation detail and so not relevant to users. The
way you must think about it (in fact, the thinking behind the auto-evalua-
tion of method containing slots) is to look at what is returned from calling
the slot. Whether the slot contains data or a method, it always returns
what looks to be the result of a method (unless the method evaluates to a
method?). If you want to add another type of slot to the scheme (as opposed
to a completely abstract feature) that is associated with any existing slot
then it has to be possible for them to be associated with slots that contain
data (the x! slot would return a method that evaluates to what's stored in x).

A user can choose to designate a slot as assignable or constant. They should
also be able to choose whether the slot will be "data only" (no associated x!
slot) or "data and method".

How much of a code base does Self have anyways? Is compatibility *that*

More information about the Self-interest mailing list