On Wed, Mar 10, 2010 at 01:56:13AM -0800, Josh Gargus wrote:
> > Hi. Someone
> 
> "Keith".
> 
> > noticed on IRC today that Object >> future (and
> > friends like futureSend: and the compiler optimization of
> > future) are kind of odd things to have in the base image.
> 
> Yes, he was temporarily away from the community during the
> discussion about it.  I added the changes to the Inbox

I see. It is useful outside the context of Croquet. Fair enough

> TFutureMaker and FutureMaker should be perfectly compatible;
> they both result in #futureSend:at:args: being sent to the
> target object.  The question is what to do with the default
> implementations of #futureSend:at:args: and #futureDo:at:args:
> in Object.

Ok. I'm looking into how to best merge Cobalt given that future
is now implemented correctly in trunk. There is also a second
type of indirect message send in Croquet, the syncSend. I think
the correct implementation of it in a non-island environment
would be to just execute the message, but I'm not sure. 

It has a corresponding TMessageMaker class (of which
TFutureMaker is a subclass). FutureMaker in trunk is identical
to a flattening of TMessageMaker and TFutureMaker. Should I
implement syncSend in trunk as well? Do I understand it's
semantics correctly?

It may be better to leave future in trunk alone and implement
syncSend in cobalt as it was before; it's semantics are rather
specific to island environments. To do this, I think I would
reverse the class hierarchy: base TMessageMaker on trunk's
FutureMaker, and drop TFutureMaker from cobalt.

Any ideas as to what I should do?

-- 
Matthew Fulmer (a.k.a. Tapple)