[squeak-dev] Object >> future
tapplek at gmail.com
Wed Mar 10 19:35:13 UTC 2010
On Wed, Mar 10, 2010 at 01:56:13AM -0800, Josh Gargus wrote:
> > Hi. Someone
> > 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
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)
More information about the Squeak-dev