slate comments

[Brian T. Rice]

At 07:19 PM 3/18/00 -0300, Alexandre Oliva wrote:
>On Mar 17, 2000, "Brian T. Rice" <water@tscnet.com> wrote:
>
>> 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.
>
>If you're going to look into supporting multiple meta-objects without
>giving up the simplicity of the one-meta-object model, you may be
>interested in Guaranį's approach.  Each object may be associated
>directly with at most one meta-object, but this meta-object may
>compose the behavior of several others, some of which can also be
>composers, and so on.  So, unless a meta-object is a composer, it can
>behave mostly as if it were the only meta-object associated with the
>object.  Only composers have to deal with the composition complexity.

Ah. I remember looking into Guaranį a year or two ago, but this was while
language design was not on my mind, so the idea didn't have much of an
impact on me. Now that I've seen this again, I can see that meta-object
composition is a natural use of the Slate object (and therefore
meta-object) model. I'm certainly going to adapt Guaranį's architecture to
Slate, now that I've seen what's possible. Of course, I'd like to know if
there are any interesting applications of the architecture that you've
found useful that aren't outlined in the papers, since I'm relatively new
to this idea.

>You may think such composition strategies can be easily accomplished
>in other MOPs, but they often can't because MOPs often aren't designed
>with this kind of hierarchical composition in mind, which leads to
>meta-objects that aren't easily combinable.

Okay, well I plan to use the Guaranį by having the composers essentially
contain the composed meta-objects within its slots. (Sharing of these
composable meta-objects is possible by cloning, which can cross-cut the
namespace scheme in Slate.) This should provide most of the features in the
architecture. Enhanced with some other Slate programming nuances I have in
mind, I might be able to wrestle quite a bit more out of it.

>The factorization of meta-object behavior in CodA is sound, but IMHO
>extending it is not as simple, because, in order to extend it, you
>have to modify or replace the standard meta-objects.  Then, when you
>want to combine multiple such modifications, you may end up in
>trouble, because they may conflict, and it may turn out to be
>impossible to combine the meta-objects you want.  That's because the
>extension of meta-objects is not disciplined, i.e., there's no
>standard interface a meta-object should implement, by means of which
>any meta-object can be plugged into the meta-system.

Okay, this is a really great viewpoint that I had not considered the first
time looking into multiple meta-objects.

>You can find a few papers about Guaranį, and a Java-based
>implementation thereof, at my home page, see below :-)
>
>-- 
>Alexandre Oliva

Thanks for the tip. :)

~