[Pharo-project] Process Tests and

Frank Shearar frank.shearar at gmail.com
Sat Jun 2 09:21:41 EDT 2012


On 2 June 2012 12:24, Igor Stasenko <siguctua at gmail.com> wrote:
> On 2 June 2012 11:40, Stefan Marr <smalltalk at stefan-marr.de> wrote:
>>
>> 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.
>
> 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 :)

And handily, in this case returning a Promise/Future means you...
simply get the resolved value!

frank

>> 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.
>




More information about the Pharo-dev mailing list