(just happened to wake up in the middle of the night after being sick all day, so I'll try to make sense)


On Mar 10, 2010, at 12:21 AM, Matthew Fulmer 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 as announced in:
http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.general/140078

Andreas did a better job of motivating the changes than I did.  In particular, he anticipates Keith's reasonable IRC question, "what's wrong with Future in: deltaMSecs send: selector to: target with: arg?".  The short answer is "convenience".
http://article.gmane.org/gmane.comp.lang.smalltalk.squeak.general/140096

As Keith seems to, Colin also felt ambivalent about changing the language with a Compiler modification.  In fact, the compiler change is merely an optimization (just like #ifTrue:).
http://article.gmane.org/gmane.comp.lang.smalltalk.squeak.general/140125

Keith and I actually touched upon this topic ourselves, but never got very deep into it.
http://article.gmane.org/gmane.comp.lang.smalltalk.squeak.general/141378
http://article.gmane.org/gmane.comp.lang.smalltalk.squeak.general/141482


> I said
> it's there for Croquet, but then I looked again, and noticed
> that Croquet actually changes the behavior of future (it uses a
> TFutureMaker rather than a FutureMaker). No idea whether the two
> implementations are compatable or not; haven't examined either
> in depth. 
> 


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.

In Croquet, every Process has an "island" variable.  When introducing these changes, I wanted to keep them as small as possible, so changing Process was out of the question as long as there are alternatives.  Project seems like a reasonable place in the trunk image (Cuis doesn't have "Project", so would have to implement the default methods differently... I won't go into this, since it is irrelevant to you porting Croquet to 4.1).  The default implementation in Project even works in MVC, and the version in MorphicProject takes advantage of existing scheduling machinery in Morphic.  Although the decision to use Project seems expedient and reasonable, it's certainly open to change if something else makes more sense later.

For porting Croquet, the simplest thing would be to override Project class>>current to look like:
	current
		^Processor activeProcess island ifNil: [CurrentProject]

This assumes that Process>>island answers nil if you're not "in" an island.  This is the behavior in a random Cobalt image on my disk.  In our images at work, "Processor activeProcess island" answers " an Island(Squeak)" if you type it into a workspace.  The implementation of Project class>>current might then look like:
	current
		| island |
		island := Processor activeProcess island.
		^(island == Island default) 
			ifTrue: [CurrentProject] 
			ifFalse: [Processor activeProcess island]



> Since I'm porting Cobalt to trunk, I may have to override this
> method in Cobalt, but I'm wondering: Why is it here in the first
> place?


Hopefully the links above provide the motivation.


> Is it something ported from Tweak? Is it something
> leftover from 3.3? Is it something else entirely like a remnant
> of Squeak-E? Or is it just a simple, if rarely used, method in
> core squeak?
> 


The last one.

Hope this helps.

Cheers,
Josh


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