2014-03-18 18:47 GMT+01:00 Clément Bera <bera.clem...@gmail.com>: > 2014-03-18 18:31 GMT+01:00 Max Leske <maxle...@gmail.com>: > > >> On 18.03.2014, at 18:17, Camille Teruel <camille.ter...@gmail.com> wrote: >> >> >> On 18 mars 2014, at 17:02, Clément Bera <bera.clem...@gmail.com> wrote: >> >> Hello, >> >> For blockClosures it is normal, block closure arguments have always been >> assignable since smalltalk-80. >> >> >> I never noticed, that's a weird 'feature'. >> >> 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 <https://pharo.fogbugz.com/default.asp?12419> is not a bug to me, >> it's a feature. >> >> >> You mean that there exist code out there that rely on being able to store >> in an argument? >> >> > Yes there are code like that, we encountered them in Opal's regression > tests (I don't remember exactly but they are in Pharo, Moose or/and > seaside). > > Squeak did allow that once upon a time, everything you allow is used (accidentally or not). It's rare but may prevent loading old packages... I'm pretty sure that some VMMaker modules did have the problem in the past...
> As Christophe said, arguments are temporary variables with an initial > value for block closures (and right now for methods too, but it's a > officially bug). Perhaps it is not a bug to allow that for methods. It's > another feature. > > It's bad for debugging because we cannot simply restart the progam counter at beginning of the method then... So there's more to loose than win with such feature IMO. The expected behavior is the same as block closures: > > MyClass>>foo > | t | > (self example: t) logCr. > ^ t > > MyClass>>example: arg > arg := 1. > ^ arg > > When evaluating MyClass new foo, 1 is logged on the transcript but the > return value is nil, because an argument is a temporary variable with an > initial value. > > On the bug tracker we noted to add a setting for these cases. That's the > solution anyway... > A richer interface is to raise (signal) an exception, and parameterize the defaultAction with such setting, or catch the exception in some tool - allways fail - allways succeed - ask user interactively whether to turn success on while loading this package or abort - ask user interactively method by method (not very user friendly ! expert mode only) - automatically fix the method (rename arg and copy it to a temp in preamble) - etc... >> Always assume the worst case scenario :p >> >> >> >> For methods it is a bug, thanks for noticing. I will check. >> >> >> >> >> 2014-03-18 15:45 GMT+01:00 Nicolai Hess <nicolaih...@web.de>: >> >>> similiar to issue 12419 <https://pharo.fogbugz.com/default.asp?12419> >>> block arguments should be read only >>> >>> >>> 2014-03-18 15:21 GMT+01:00 Camille Teruel <camille.ter...@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 <siguc...@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. >>>> >>>> >>>> >>> >> >> >> >
