use of method temporaries in callback blocks?

> Hi,
>
> Is it correct that method temporaries cannot be used in Gemstone to communicate values between (ajax) callbacks?
>
> In Pharo, doing the following works fine, but not in Gemstone where the use of the temporary value in the second block remains at its initial value.
> Replacing the temporary by an instance variable works fine but pollutes the component imho.
>
> | temp |
> (html jQuery ajax
> callback: [:values | temp := values ] passengers: (... some jQuery exp ...);
> onComplete: (html jQuery ajax script: [:s | s << ... do something with temp ...]))
>
>
> best regards,
> Johan

> Johan,
>
> Yes method temps are problematic (we do not follow the ANSI standard
>
> For Issue 152, we had a similar problem and used the following as a workaround:
>
> Original JQAutoComplete>>sourceCallback: method:
>
>  sourceCallback: aOneArgumentBlock
>    | term |
>    self source: ((self jQuery getJson
>        text: [ :stream |
>                stream json: (aOneArgumentBlock value: term) ];
>        callback: [ :value | term := value ]
>          value: (JSStream on: 'request.term');
>        onComplete: 'response(arguments[0])';
>        dataType: 'jsonp') asFunction: #('request' 'response'))
>
> In this case 'term' is the problematic temp. In addition to instance variables, one can use method arguments to "replace" the temp (see WALotsaLinksFunctionalTest and WALotsaLinksGemStoneFunctionalTest for a simple example  where the temp variable is read only).
>
> Since 'term' is written, we can arrange to create argument to the method that has an object into which the temporary value can be written from the callback block and then read in another block.
>
> Here's the with workaround we used:
>
>  sourceCallback: aOneArgumentBlock
>    self sourceCallback: aOneArgumentBlock assoc: Association new
>
> and new method JQAutoComplete>>sourceCallback:assoc:
>
> sourceCallback: aOneArgumentBlock assoc: assoc
>    self source: ((self jQuery getJson
>        text: [ :stream |
>                stream json: (aOneArgumentBlock value: assoc value ];
>        callback: [ :value | assoc value: value ]
>          value: (JSStream on: 'request.term');
>        onComplete: 'response(arguments[0])';
>        dataType: 'jsonp') asFunction: #('request' 'response'))
>
> We will be fixing this particular bug in 3.0, but for 2.x the fix would involve some significant changes to the way that blocks are handled, so you'l have to workaround these cases...
>
> Dale
>
> Johan Brichau wrote:
>> Hi,
>> Is it correct that method temporaries cannot be used in Gemstone to communicate values between (ajax) callbacks?
>> In Pharo, doing the following works fine, but not in Gemstone where the use of the temporary value in the second block remains at its initial value.
>> Replacing the temporary by an instance variable works fine but pollutes the component imho.
>> | temp |
>> (html jQuery ajax
>> callback: [:values | temp := values ] passengers: (... some jQuery exp ...);
>> onComplete: (html jQuery ajax script: [:s | s << ... do something with temp ...]))
>> best regards,
>> Johan
>

> Hi Dale,
>
> Thanks for the feedback.
> An alternative I was indeed going ti try is to store a valueholder in the temp and use that to transport the value from one block to another. I think that makes for the least changes to all the places we have to rely on this. Is there a reason why you propose to use a separate method for the block in this case?
>
> Best regards,
> Johan
>
> On 27 Aug 2010, at 19:02, Dale Henrichs <[hidden email]> wrote:
>
>> Johan,
>>
>> Yes method temps are problematic (we do not follow the ANSI standard
>>
>> For Issue 152, we had a similar problem and used the following as a workaround:
>>
>> Original JQAutoComplete>>sourceCallback: method:
>>
>>  sourceCallback: aOneArgumentBlock
>>    | term |
>>    self source: ((self jQuery getJson
>>        text: [ :stream |
>>                stream json: (aOneArgumentBlock value: term) ];
>>        callback: [ :value | term := value ]
>>          value: (JSStream on: 'request.term');
>>        onComplete: 'response(arguments[0])';
>>        dataType: 'jsonp') asFunction: #('request' 'response'))
>>
>> In this case 'term' is the problematic temp. In addition to instance variables, one can use method arguments to "replace" the temp (see WALotsaLinksFunctionalTest and WALotsaLinksGemStoneFunctionalTest for a simple example  where the temp variable is read only).
>>
>> Since 'term' is written, we can arrange to create argument to the method that has an object into which the temporary value can be written from the callback block and then read in another block.
>>
>> Here's the with workaround we used:
>>
>>  sourceCallback: aOneArgumentBlock
>>    self sourceCallback: aOneArgumentBlock assoc: Association new
>>
>> and new method JQAutoComplete>>sourceCallback:assoc:
>>
>> sourceCallback: aOneArgumentBlock assoc: assoc
>>    self source: ((self jQuery getJson
>>        text: [ :stream |
>>                stream json: (aOneArgumentBlock value: assoc value ];
>>        callback: [ :value | assoc value: value ]
>>          value: (JSStream on: 'request.term');
>>        onComplete: 'response(arguments[0])';
>>        dataType: 'jsonp') asFunction: #('request' 'response'))
>>
>> We will be fixing this particular bug in 3.0, but for 2.x the fix would involve some significant changes to the way that blocks are handled, so you'l have to workaround these cases...
>>
>> Dale
>>
>> Johan Brichau wrote:
>>> Hi,
>>> Is it correct that method temporaries cannot be used in Gemstone to communicate values between (ajax) callbacks?
>>> In Pharo, doing the following works fine, but not in Gemstone where the use of the temporary value in the second block remains at its initial value.
>>> Replacing the temporary by an instance variable works fine but pollutes the component imho.
>>> | temp |
>>> (html jQuery ajax
>>> callback: [:values | temp := values ] passengers: (... some jQuery exp ...);
>>> onComplete: (html jQuery ajax script: [:s | s << ... do something with temp ...]))
>>> best regards,
>>> Johan

> I haven't actually tried that technique and it seems that it should work ... if it does work then it is a superior fix, as the extra method would'nt be needed:)
>
> Dale
>
> Johan Brichau wrote:
>> Hi Dale,
>> Thanks for the feedback. An alternative I was indeed going ti try is to store a valueholder in the temp and use that to transport the value from one block to another. I think that makes for the least changes to all the places we have to rely on this. Is there a reason why you propose to use a separate method for the block in this case?
>> Best regards,
>> Johan
>> On 27 Aug 2010, at 19:02, Dale Henrichs <[hidden email]> wrote:
>>> Johan,
>>>
>>> Yes method temps are problematic (we do not follow the ANSI standard
>>>
>>> For Issue 152, we had a similar problem and used the following as a workaround:
>>>
>>> Original JQAutoComplete>>sourceCallback: method:
>>>
>>> sourceCallback: aOneArgumentBlock
>>>   | term |
>>>   self source: ((self jQuery getJson
>>>       text: [ :stream |
>>>               stream json: (aOneArgumentBlock value: term) ];
>>>       callback: [ :value | term := value ]
>>>         value: (JSStream on: 'request.term');
>>>       onComplete: 'response(arguments[0])';
>>>       dataType: 'jsonp') asFunction: #('request' 'response'))
>>>
>>> In this case 'term' is the problematic temp. In addition to instance variables, one can use method arguments to "replace" the temp (see WALotsaLinksFunctionalTest and WALotsaLinksGemStoneFunctionalTest for a simple example  where the temp variable is read only).
>>>
>>> Since 'term' is written, we can arrange to create argument to the method that has an object into which the temporary value can be written from the callback block and then read in another block.
>>>
>>> Here's the with workaround we used:
>>>
>>> sourceCallback: aOneArgumentBlock
>>>   self sourceCallback: aOneArgumentBlock assoc: Association new
>>>
>>> and new method JQAutoComplete>>sourceCallback:assoc:
>>>
>>> sourceCallback: aOneArgumentBlock assoc: assoc
>>>   self source: ((self jQuery getJson
>>>       text: [ :stream |
>>>               stream json: (aOneArgumentBlock value: assoc value ];
>>>       callback: [ :value | assoc value: value ]
>>>         value: (JSStream on: 'request.term');
>>>       onComplete: 'response(arguments[0])';
>>>       dataType: 'jsonp') asFunction: #('request' 'response'))
>>>
>>> We will be fixing this particular bug in 3.0, but for 2.x the fix would involve some significant changes to the way that blocks are handled, so you'l have to workaround these cases...
>>>
>>> Dale
>>>
>>> Johan Brichau wrote:
>>>> Hi,
>>>> Is it correct that method temporaries cannot be used in Gemstone to communicate values between (ajax) callbacks?
>>>> In Pharo, doing the following works fine, but not in Gemstone where the use of the temporary value in the second block remains at its initial value.
>>>> Replacing the temporary by an instance variable works fine but pollutes the component imho.
>>>> | temp |
>>>> (html jQuery ajax
>>>> callback: [:values | temp := values ] passengers: (... some jQuery exp ...);
>>>> onComplete: (html jQuery ajax script: [:s | s << ... do something with temp ...]))
>>>> best regards,
>>>> Johan
>