[Pharo-project] Process Tests and
smalltalk at stefan-marr.de
Sat Jun 2 05:40:36 EDT 2012
On 02 Jun 2012, at 11:07, Igor Stasenko wrote:
> On 2 June 2012 10:28, Stefan Marr <smalltalk at stefan-marr.de> wrote:
>> Hi Sean:
>> On 02 Jun 2012, at 05:07, Sean P. DeNigris wrote:
>>> During the process, I noticed that the Blue Book specifies that #fork
>>> returns the block itself (pg. 252), while in Pharo it returns the process
>>> (see #testFork in the slice). Should our implementation be changed to match
>>> the Blue Book?
>> Why would it be desirable to have the block?
>> How would you obtain the process object after your change?
> by using #newProcess.
> using the return value of fork provokes you to write incorrect concurrent code.
> for instance, i found once, some code which assumes that forked
> process not yet started,
> or not yet terminated, and people trying to do something with process
> immediately after issuing #fork.
So, just because somebody made a mistake, the whole thing is not worthwhile anymore?
What is the value of having the direct reference to the block?
What are you going to do with it?
I would buy an argument that #fork should return a promise (or you can call it future if you like) to the return value of the block.
I don't see how the block itself would be of any use.
I do see however, that the block (i.e., self) was returned in earlier versions just because of convention, and no further thought.
[Some people claim that the whole idea of Process in Smalltalk was never fully thought out anyway. (And that's not me.)]
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
Phone: +32 2 629 2974
Fax: +32 2 629 3525
More information about the Pharo-dev