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

[Richard]

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

That's another thing. Consider,
in my little Smalltalk project I'm working with a link and node graph where
the objects of interest are the nodes and the links are named. It looks a lot
like a Dictionary that contains other dictionaries. The difference is that the
links are /not/ variables but objects with interesting properties of their own.
So in fact, this looks a lot like Self and I do want to make it look like Self.
In particular, I want someone to be able to write;

	outside room1 room2 room3
	^                   ^
	initial node        name of 3rd link in chain

Now consider what happens when I have to implement this. 'room1' isn't a method,
it's a link name. And if I implemented this in Self, it wouldn't change a thing
since 'room1' is not a slot of the object in the pseudo-variable 'outside'.
Moreover, when I go to implement the user interface, I want to be able to write
something like;

| room1 room2 room3 |

room1 := 'firstDoor'.
room2 := 'secondDoor'.
room3 := 'thirdDoor'.
outside room1 room2 room3.

And I know that a user "can" write;

((outside perform: 'firstDoor') perform: 'secondDoor') perform: thirdDoor.

but frankly, I don't consider that to be a sensible definition of "can".

(Until I learned about Self, I was perfectly happy with writing
outside passTo: #('firstDoor' 'secondDoor') selector: 'thirdDoor'
but now that I see just how procedural that feels like, I can't
tolerate it.)

So in my case the "method names" aren't literals, they're variables. And
not variables to symbols but to arbitrary objects. While I'm at it, it
wouldn't hurt if the "method names" could be any bracketed expression ....

I realize that infix notation poses problems for mixing of operators
and operands, and I'm not willing to give up the notation, but I find
myself precisely in the position of needing to mix (unary) operators
and operands. Unless, of course, I'm missing something terribly obvious,
as I've done numerous times before. :-)

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

If autoevaluation is enabled then what would the following return?
value
	| x |
	x = self.
	x

Unless people get into the habit of storing methods using x: and getting them
back at x!, I don't see a way around having a distinction between methods and
blocks.

> 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 :-)

This seems eminently sensible.