Issue 219 in glassdb: to:do: block parameter not captured by closure in loop

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium GLASS-Server Version-GLASS0.231

New issue 219 by [hidden email]: to:do: block parameter not captured  
by closure in loop
http://code.google.com/p/glassdb/issues/detail?id=219

testClosureParameters
        | closures |
        closures := OrderedCollection new.
        1 to: 5 do: [:val |
                closures add: [val] ].
       
        closures do: [:aClosure |
                Transcript show: aClosure value asString; cr ]

On Gemstone unexpectedly results in:
5
5
5
5
5

On Pharo results in a more expected:
1
2
3
4
5


However if the loop becomes: #(1 2 3 4 5) do: the results are as expected

Comment #1 on issue 219 by [hidden email]: to:do: block parameter not  
captured by closure in loop
http://code.google.com/p/glassdb/issues/detail?id=219

A more complete text example would be:

testToDoClosureParameters
        | closures |
        closures := OrderedCollection new.
        1 to: 5 do: [:val |
                closures add: [val] ].
       
        1 to: 5 do: [:val |
                self assert: val equals: (closures at: val) value ]

Updates:
        Status: Accepted
        Labels: -Version-GLASS0.231 Version-2.4.x

Comment #2 on issue 219 by [hidden email]: to:do: block parameter not  
captured by closure in loop
http://code.google.com/p/glassdb/issues/detail?id=219

Nick this is a "known bug" although I don't see a glassdb bug on this  
one ... so this bug will act as the marker.

In GemStone/S 2.x, block temporaries are shared across invocations of a  
nested blocks so that the last value of the temporary is the value in  
all "copies" of the block.

The workaround is to not use block temporaries to for values that are to be  
shared between blocks.

If you take a look at the WALotsaLinksFunctionalTest you will see the same  
bad behavior that you've documented. The WALotsaLinksGemStoneFunctionalTest  
is an implementation that works around the block temp bug.

Also see Issue 152 and Issue 221 for additional examples.

We expect to fix this bug in GemStone3.0

Updates:
        Labels: bugid-38359

Comment #3 on issue 219 by [hidden email]: to:do: block parameter not  
captured by closure in loop
http://code.google.com/p/glassdb/issues/detail?id=219

Internal Gemstone bug38359: Nested block variable resolution