slate comments

[Jecel Assumpcao Jr.]

Brian T. Rice wrote:
> >[Dinnerbell language]
> No, I hadn't seen this before. It's definitely interesting, but I've seen
> the idea before in Maude's object-oriented modules where object behavior is
> determined by equational rewrite rules. I'm of the opinion that this
> complication placed on the programmer's shoulders to maintain the
> message-queue structure is an unnecessary result of the syntax of the
> message specification. However, Slate will simply be dealing with it at the
> level of implementation, which I intend to provide openly to advanced
> programmers. It definitely points out some interesting fine detail of the
> message-history ontology of objects.

Yes, I mentioned it as a source for interesting ideas, not as an example to
follow. Solving these problems (concurrent state management) by making things
so low level that the programmer has to figure the nasty details out by himself
is a good way to solve toy problems, but not to write real systems.

> I haven't seriously considered the multiple meta-object idea since I was
> trying to focus on simplicity for the user who delves into the meta-object
> system in Slate, but I'm taking a look at the CodA documents that are still
> available to see if the idea is workable. I'll let you know what I get from
> them.

The key point in CodA was decoupling message sending from message receiving so
that you could implement several different models of parallel and remote
execution.
   
> >[Self has immutable slots]
> 
> Okay, it seems that I fell short of using the right terminology, then. I'm
> trying to encapsulate two different ideas into one term "mutability".
> Essentially the issue in mutability is, "What happens to the object if you
> try to mutate slot x?". I'm adding to that this, "What happens to the
> *environment* if you try to mutate slot x?". This is where I believe I can
> add a meaningful MOP that can be customized to a very extensive degree. For
> instance, one might have a change to slot X create a new temporary context
> that gets thrown away when the computation returns, perhaps even dependent
> on the result of the code. Alternatively, one could have objects' accessors
> create new objects in the same hierarchy with the new state without
> bothering the old state. This could apply not just to objects but entire
> namespaces that contain the objects whose state is muted, as well as
> specified parts of the inheritance chain or the meta-object chain and its
> hierarchy.

Right, this allows you to have total control over the semantics of object state
changes. I am having to deal with this in my distributed persistent object
store system (at a much larger grain, of course, and with much less flexibility
than you have).

> Notice that if you count the system-level slots of each object, like
> 'parent', 'meta', '..' (parent namespace), 'clone', and such, then you can
> get some interesting protection features available to the programmer. In
> particular, 'clone' meta-behavior turns out to be extremely powerful in
> making the object structure fit a particular conceptual model.

What is the difference between "parent" and ".."?

> Now that I consider it, it's possible that a multiple meta-object
> interaction might help with factoring behavioral meta-object functionality,
> but I'd need to find some existing working designs to adapt because
> creating and working through such design ideas from scratch would take a
> lot of effort.

The idea is that you can "snap together" a few dozen meta-objects in hundreds
of different ways, instead of writing hundreds of different meta-objects by
hand. With a good framework, like the Guaranį system mentioned in a parallel
thread, you can even mostly automate this configuration process.

> So the difference is that I don't try to just "remove" the accessor method,
> I keep it in the object and allow its meta-behavior to be dynamically
> changed without affecting the original object. Of course, I'll provide
> simple mechanisms that will allow one to migrate the desired part of the
> meta-behavior of an object along with the object as a coherent unit. This
> would allow meta-behavior migration to be customized to a fine degree to
> support the various applications of the idea of meta-behavior.

Yes, it is possible to do better than Self's immutable slots. I was just
mentioning the fact that they existed. In fact, in previous versions of Self
which had slot privacy and lookup-tie-breaker-rules they had much richer (but
confusing) semantics.

My own system is a multiuser one, so objects might be immutable due to the fact
that the logged in user doesn't have write permission for them. Both the
compiler and the scheduler can do optimizations based on this.

 > I want to use the MOP to allow Slate to express naturally as many 
> programming styles as possible, even to the point of building the literal
> system (mathematics, logic, text, graphics, etc) using the basic object
> metaphor along with a customized set of meta-behavior. To this end, I'm
> looking at structural reflection being built into the default MOP library,
> either by multiple meta-objects or using simpler methods.

Of course you have to have structural reflection of some sort - otherwise you
can't write the Slate development system in Slate!

-- Jecel