Hi Cl�ment,


On Tue, Mar 18, 2014 at 9:02 AM, Cl�ment Bera <bera.clement@gmail.com> wrote:
Hello,

For blockClosures it is normal, block closure arguments have always been assignable since smalltalk-80. We could add a warning to discourage it, but we cannot forbid it, or we will not be able to load lots of frameworks and libraries that use it. So�12419�is not a bug to me, it's a feature.

For methods it is a bug, thanks for noticing. I will check.

Well, in VW and Squeak it is disallowed, but there is a flag one can set to allow it. �I think it best to disallow. One can always rewrite the code, and indeed create an automatic rewriter, �The pattern is quite simple, and was applied to the Smalltalk-80 V2 code base when VisualWorks' predecessor ObjectsWorks 2.3 moved to ObjectWorks 2.4 which had proper closures:


someMethod
� � [:blockTemp| ... blockTemp := <expr> ...

=>

someMethod
� � | blockTemp |
� � [:blockTempx| blockTemp := blockTempx. �... blockTemp := <expr> ...


One would occasionally see this pattern also:


someMethod
� � | blockTemp |
� � [:blockTemp| ... ]
� � blockTemp := <expr> ...

=>

someMethod
� � | blockTemp |
� � [:blockTempx| blockTemp := blockTempx. �...�]
� � blockTemp := <expr> ...

So disallowing it and providing a rewriting tool is an option. �But I think the flag is best, with its default setting being to ban assignments to block arguments.

HTH





2014-03-18 15:45 GMT+01:00 Nicolai Hess <nicolaihess@web.de>:

similiar to issue 12419� block arguments should be read only


2014-03-18 15:21 GMT+01:00 Camille Teruel <camille.teruel@gmail.com>:

Indeed, I can compile:

C>>foo: arg
� � � � ^ arg := 3

And 'C new foo: 1' returns 3...


On 18 mars 2014, at 15:16, Igor Stasenko <siguctua@gmail.com> wrote:

> extent: newExtent
>
> � � vertical
> � � � � ifTrue: [ newExtent := self �defaultWidth @ newExtent y ]
> � � � � ifFalse: [ newExtent := newExtent x @ self �defaultWidth ].
>
> � � super extent: newExtent
>
> Can you verify it? Arguments should be not assignable.
>
> --
> Best regards,
> Igor Stasenko.







--
best,
Eliot