On 3/10/2010 11:35 AM, Matthew Fulmer wrote:
> 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?

The message #syncSend: is not meaningful outside of Croquet, and even in 
Croquet it's a bit of a hack. As a consequence there is no point in 
introducing it in Squeak in general.

TMessageMaker / TFutureMaker: I would recommend keeping both and simply 
leave the implementation of Object>>future alone. There is no harm in 
having an extra class for historical reasons until you feel confident 
about the system.

Rebasing TMessageMaker on FutureMaker: You could do that, but I 
wouldn't. A TMessageMaker isn't a FutureMaker, it's actually a different 
beast. Unless you feel very strongly that you don't want to duplicate a 
handful of methods, I'd leave it alone.

Cheers,
   - Andreas