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

[Richard]

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?

> > Yes, but that may be a mistake. After all, x: is still a special
> > slot (specially connected to x) regardless of whether it exists
> > or not.
> 
> My example does have a "mom:" slot but no "dad:" slot. In fact, I can
> add a "dad:" slot to that object that has a normal method that does
> something other than change the corresponding "dad" constant data slot.

Good point. It does show that whatever the syntax chosen for the "method"
slots I propose must always be some valid slot name. Unfortunaly, neither
x:: nor x:! are valid slot names, currently.

> > I think that either any slot must be able to write to
> > any other slot, or that slots should /explicitly/ (instead of
> > only implicitly) come in pairs/triples.
> 
> Again, this is a valid option. And note that if you implement one
> design in the language, you can support an alternative in the
> programming interface. So you can have it both ways at the same time.

Yes, but the ease of providing an alternative programming interface
is generally not symmetric. A few months ago, I argued over where and
how file metadata should be stored (embedded in the filename or as a
separate property); it turns out to be a LOT easier and cleaner to
create a "separate property" interface over an "embedded in the names"
filesystem than vice versa.

It's a lot easier to provide a clunky interface over a clean design
than vice versa. Of course, that leaves the question of which is
clunky and which is clean to be decided.

> The "public/private" thing in previous versions of Self affected the
> message lookup algorithm. Private slots would be found when looking up
> messages sent to self, but not for messages sent by other objects.
> That, combined with parent priorities and other things, turned out to
> complicate things and was dropped until a better design can be found.
> There is no relation with write slots at all (except that the privacy
> of the data and write slots could be set separately for some
> interesting effects).

Not least of which would be a public write method to a private assignable
slot, I imagine. I would definitely find this useful.

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

> Object creation would have been complicated back in the text based days
> of Self without the special syntax. Now that everything is graphical,
> this is not such a big issue.
> 
> But "ex nilo" creation of objects *is* a big issue in prototype based
> languages. If all objects are created from copying and changing other
> objects, where did the first one come from? And how do you express this
> "changing an object"?
> 
> Self's primitives, such as _AddSlots:, have the unfortunate feature of
> not solving this problem. They take an object as an argument (and where
> did *that* come from?):
> 
>     ( | x <- 10 | ) _AddSlots: ( | y <- 15. parent* = traits point | )
> 
> If we had something more like "_AddSlotNamed:WithValue:" then it would
> be possible to bootstrap the system without a parser that started out
> knowing the slot initialization syntax.

Interesting.

As for the Original Object, it surely comes from outside the image (or
was created at the same time as the image) and asking how it was created
is no more meaningful than asking what came before the Big Bang.

> In theory you could write
> 
>     ( | x = 10. x: = <- | )
> 
> instead of
> 
>    ( | x <- 10 | )
> 
> I don't have my Sun around here to test it, but tinySelf 0 complains
> about a syntax error in the first version. You can write
> 
>    ( | x = 10. x: = ( | :arg | arg * arg ) | )
> 
> so you can see that the association between "x" and "x:" isn't entirely
> automatic.

Yes, I see.

I thank you for the interesting comments.