slate comments

[Brian T. Rice]

At 05:55 PM 3/22/00 -0300, Alexandre Oliva wrote:
>On Mar 22, 2000, "Brian T. Rice" <water@tscnet.com> wrote:
>
>> At 08:47 PM 3/21/00 -0300, Jecel Assumpcao Jr. wrote:
>
>>> 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.
>
>> Okay, this did interest me as an issue, but I thought it would be a bit
>> difficult to work in without some confusion related to the semantics of
>> each part of the message-send (send and receive). To me, this dichotomy of
>> the message-send mirrors the lookup+apply idea of moostrap. How is it
>> different in its most appropriate usage? Does it make the lookup+apply
>> model obsolete? Can they co-exist peacefully? Sorry to be so inquisitive,
>> but I (and I suspect most other people) haven't explored these ideas
>> adequately. It just seems that it would be confusing to the MOP user to
>> place his desired modifications in such a framework as send+receive unless
>> it had to do specifically with distribution or timing. It would seem
>> especially so if the lookup+apply model were mixed with it.
>
>I'm not sure I have answers to your questions.  But I'd like to add
>that decoupling send+receive can be easily attained by introducing a
>proxy between the sender and the receiver, arranging for the sender to
>send messages to the proxy instead of directly to the receiver, and
>making the send-side processing at the receive meta-objects of the
>proxy.  So, the send meta-object is unnecessary, which is why this
>concept is not present in the core of Guaranį.  Which doesn't mean it
>is not convenient, for introducing and managing proxies isn't as
>simple, as we have later found out :-)

I am not surprised at all that the proxy concept is complex to manage. I
have, however, found out how to implement send+receive interception using
Slate and its moostrap-style meta-objects. It basically involves having a
clone-as-proxy placed "sufficiently close" to the object sender (perhaps
done dynamically?) and then intercepting the clone's reception of the
message. The clone would then merely forward the message to the ultimate
object in the proxy chain. However, this assumes that *every* meta-object
in a delegation chain gets to intercept messages. The alternative is to
introduce wrapper-as-proxy objects which forward all messages to their
wrapped object, and this seems much more manageable.

When you take this concept and couple it to a model of a distribution
network as a structure of namespaces, you can identify a namespace with one
domain and simply place the proxy there. At any rate, this verifies that
Slate can handle the semantics of this idea using its dynamic
object-instantiation and meta-behavior specification features.

>>>Brian T. Rice wrote:
>>>> 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.
>> Yes, this is what impressed me so much about the idea, especially if
>> I can manage to implement it with Composer meta-objects simply
>> containing the meta-objects (their clones) to which they delegate.
>
>I'm not sure I understand what you mean by ``their clones'', but it
>appears to me that you got the general idea.  But beware that the
>interface of your meta-objects must be carefully designed to allow for
>hierarchical composition.  It took us a very long time massaging the
>interface of MetaObject in Guaranį until we got to the final form.
>(Or should I say current form, as it might change?)

Well, Slate's prototype-based, with cloning as a message-send, so clone
identity can be managed by meta-behavior. So, when in Slate I need to have
a copy of an object (shallow or deep to an nth-level), I can handle it with
a simple clone and meta-behavior specification (which can be dynamically
inherited or mixed-in).

And I am definitely paying very close attention to meta-object design right
now, weighing various schemes and their safety, etc. When I get a workable,
Tunes-friendly design layed out, I'll be sure to present the idea for
criticism here. :)

However, I think a lot of the problems in designing Guaranį would have been
less prominent if another language besides Java were used. It has too many
inflexibilities for my (and Tunes') tastes.

>-- 
>Alexandre Oliva    Enjoy Guaranį, see http://www.ic.unicamp.br/~oliva/
>Cygnus Solutions, a Red Hat company        aoliva@{redhat, cygnus}.com
>Free Software Developer and Evangelist    CS PhD student at IC-Unicamp
>oliva@{lsd.ic.unicamp.br, gnu.org}   Write to mailing lists, not to me

~