On 2 June 2012 11:40, Stefan Marr <[email protected]> wrote: > > On 02 Jun 2012, at 11:07, Igor Stasenko wrote: > >> On 2 June 2012 10:28, Stefan Marr <[email protected]> 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.
agreed. I didn't said that returning block has any value.. just noted that returning a process is not much more valuable. Because there is a good chances that the process which you get is already terminated :) > 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.)] > > Best regards > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > -- Best regards, Igor Stasenko.
