slate comments

[Alexandre Oliva]

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

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

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