Just found, i can compile this:
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.
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.
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.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.
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<https://pharo.fogbugz.com/default.asp?12419> is not a bug to me, it's a feature. For methods it is a bug, thanks for noticing. I will check. 2014-03-18 15:45 GMT+01:00 Nicolai Hess <nicolaihess@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.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.
Why arguments should be read only? They are just temporary variables with an initial value.
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.
On Tue, Mar 18, 2014 at 10:10 AM, Christophe Demarey < Christophe.Demarey@inria.fr> wrote:
Why arguments should be read only? They are just temporary variables with an initial value.
Read the blue book. It was a decision of the language designers to forbid assignment to arguments to allow debugging. The assignment to block arguments is a side-effect of the old BlockContext implementation of blocks where block arguments were mapped onto temporary variables of the home context. It is an anachronism and should be forbidden also. 2014-03-18 15:45 GMT+01:00 Nicolai Hess <nicolaihess@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.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
Le 18 mars 2014 à 19:50, Eliot Miranda a écrit :
On Tue, Mar 18, 2014 at 10:10 AM, Christophe Demarey <Christophe.Demarey@inria.fr> wrote: Why arguments should be read only? They are just temporary variables with an initial value.
Read the blue book. It was a decision of the language designers to forbid assignment to arguments to allow debugging. The assignment to block arguments is a side-effect of the old BlockContext implementation of blocks where block arguments were mapped onto temporary variables of the home context. It is an anachronism and should be forbidden also.
Thank you for the explanation. I'm just curious why it is so difficult to implement a debugger if arguments are assignable? If you need to restart the execution of a method, and so you need to get the initial value of the argument, I understand you cannot find the value anymore in the method context but it is available in the caller context, no? As I never implemented a debugger, I cannot figure out the difficulties.
Hi Christophe, On Mar 19, 2014, at 1:45 AM, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:
Le 18 mars 2014 à 19:50, Eliot Miranda a écrit :
On Tue, Mar 18, 2014 at 10:10 AM, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:
Why arguments should be read only? They are just temporary variables with an initial value.
Read the blue book. It was a decision of the language designers to forbid assignment to arguments to allow debugging. The assignment to block arguments is a side-effect of the old BlockContext implementation of blocks where block arguments were mapped onto temporary variables of the home context. It is an anachronism and should be forbidden also.
Thank you for the explanation. I'm just curious why it is so difficult to implement a debugger if arguments are assignable? If you need to restart the execution of a method, and so you need to get the initial value of the argument, I understand you cannot find the value anymore in the method context but it is available in the caller context, no? As I never implemented a debugger, I cannot figure out the difficulties.
the args are no longer available; they get moved from the caller context to the callee. If you think about stack frames then what happens is that the slots containing the outgoing arguments are used as the slots for the incoming arguments. So if arguments are assigned to they are indeed lost. But look at how many methods in the system (or in any system). The proportion of methods/functions/procedures that could be written to assign their arguments is very small so the Smalltalk trade off is a good one. Eliot (phone)
Hi Eliot, Le 19 mars 2014 à 16:25, Eliot Miranda a écrit :
Hi Christophe,
On Mar 19, 2014, at 1:45 AM, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:
Le 18 mars 2014 à 19:50, Eliot Miranda a écrit :
On Tue, Mar 18, 2014 at 10:10 AM, Christophe Demarey <Christophe.Demarey@inria.fr> wrote: Why arguments should be read only? They are just temporary variables with an initial value.
Read the blue book. It was a decision of the language designers to forbid assignment to arguments to allow debugging. The assignment to block arguments is a side-effect of the old BlockContext implementation of blocks where block arguments were mapped onto temporary variables of the home context. It is an anachronism and should be forbidden also.
Thank you for the explanation. I'm just curious why it is so difficult to implement a debugger if arguments are assignable? If you need to restart the execution of a method, and so you need to get the initial value of the argument, I understand you cannot find the value anymore in the method context but it is available in the caller context, no? As I never implemented a debugger, I cannot figure out the difficulties.
the args are no longer available; they get moved from the caller context to the callee. If you think about stack frames then what happens is that the slots containing the outgoing arguments are used as the slots for the incoming arguments. So if arguments are assigned to they are indeed lost.
ok, I understand. Thank you for the explanation.
But look at how many methods in the system (or in any system). The proportion of methods/functions/procedures that could be written to assign their arguments is very small so the Smalltalk trade off is a good one.
I agree we don't really loose something. You can always assign arguments to temporary variables and update temporary variables. My point was just: if possible, why don't do it? Christophe.
On Thu, Mar 20, 2014 at 2:03 AM, Christophe Demarey < Christophe.Demarey@inria.fr> wrote:
Hi Eliot,
Le 19 mars 2014 à 16:25, Eliot Miranda a écrit :
Hi Christophe,
On Mar 19, 2014, at 1:45 AM, Christophe Demarey < Christophe.Demarey@inria.fr> wrote:
Le 18 mars 2014 à 19:50, Eliot Miranda a écrit :
On Tue, Mar 18, 2014 at 10:10 AM, Christophe Demarey < Christophe.Demarey@inria.fr> wrote:
Why arguments should be read only? They are just temporary variables with an initial value.
Read the blue book. It was a decision of the language designers to forbid assignment to arguments to allow debugging. The assignment to block arguments is a side-effect of the old BlockContext implementation of blocks where block arguments were mapped onto temporary variables of the home context. It is an anachronism and should be forbidden also.
Thank you for the explanation. I'm just curious why it is so difficult to implement a debugger if arguments are assignable? If you need to restart the execution of a method, and so you need to get the initial value of the argument, I understand you cannot find the value anymore in the method context but it is available in the caller context, no? As I never implemented a debugger, I cannot figure out the difficulties.
the args are no longer available; they get moved from the caller context to the callee. If you think about stack frames then what happens is that the slots containing the outgoing arguments are used as the slots for the incoming arguments. So if arguments are assigned to they are indeed lost.
ok, I understand. Thank you for the explanation.
But look at how many methods in the system (or in any system). The proportion of methods/functions/procedures that could be written to assign their arguments is very small so the Smalltalk trade off is a good one.
I agree we don't really loose something. You can always assign arguments to temporary variables and update temporary variables. My point was just: if possible, why don't do it?
It's that tricky trade-off between value and cost. Is it worth it? Does doing it provide as much value as doing what it displaces (opportunity cost). IMO it simply doesn't provide enough value, and there are different priorities in the compiler. But if you disagree implement it your self and then it'll be done. -- best, Eliot
On 20 March 2014 17:04, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Thu, Mar 20, 2014 at 2:03 AM, Christophe Demarey < Christophe.Demarey@inria.fr> wrote:
Hi Eliot,
Le 19 mars 2014 à 16:25, Eliot Miranda a écrit :
Hi Christophe,
On Mar 19, 2014, at 1:45 AM, Christophe Demarey < Christophe.Demarey@inria.fr> wrote:
Le 18 mars 2014 à 19:50, Eliot Miranda a écrit :
On Tue, Mar 18, 2014 at 10:10 AM, Christophe Demarey < Christophe.Demarey@inria.fr> wrote:
Why arguments should be read only? They are just temporary variables with an initial value.
Read the blue book. It was a decision of the language designers to forbid assignment to arguments to allow debugging. The assignment to block arguments is a side-effect of the old BlockContext implementation of blocks where block arguments were mapped onto temporary variables of the home context. It is an anachronism and should be forbidden also.
Thank you for the explanation. I'm just curious why it is so difficult to implement a debugger if arguments are assignable? If you need to restart the execution of a method, and so you need to get the initial value of the argument, I understand you cannot find the value anymore in the method context but it is available in the caller context, no? As I never implemented a debugger, I cannot figure out the difficulties.
the args are no longer available; they get moved from the caller context to the callee. If you think about stack frames then what happens is that the slots containing the outgoing arguments are used as the slots for the incoming arguments. So if arguments are assigned to they are indeed lost.
ok, I understand. Thank you for the explanation.
But look at how many methods in the system (or in any system). The proportion of methods/functions/procedures that could be written to assign their arguments is very small so the Smalltalk trade off is a good one.
I agree we don't really loose something. You can always assign arguments to temporary variables and update temporary variables. My point was just: if possible, why don't do it?
It's that tricky trade-off between value and cost. Is it worth it? Does doing it provide as much value as doing what it displaces (opportunity cost). IMO it simply doesn't provide enough value, and there are different priorities in the compiler. But if you disagree implement it your self and then it'll be done.
self := super agreed.
-- best, Eliot
-- Best regards, Igor Stasenko.
Hi Eliot, Le 20 mars 2014 à 17:04, Eliot Miranda a écrit :
On Thu, Mar 20, 2014 at 2:03 AM, Christophe Demarey <Christophe.Demarey@inria.fr> wrote: Hi Eliot,
Le 19 mars 2014 à 16:25, Eliot Miranda a écrit :
Hi Christophe,
On Mar 19, 2014, at 1:45 AM, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:
Le 18 mars 2014 à 19:50, Eliot Miranda a écrit :
On Tue, Mar 18, 2014 at 10:10 AM, Christophe Demarey <Christophe.Demarey@inria.fr> wrote: Why arguments should be read only? They are just temporary variables with an initial value.
Read the blue book. It was a decision of the language designers to forbid assignment to arguments to allow debugging. The assignment to block arguments is a side-effect of the old BlockContext implementation of blocks where block arguments were mapped onto temporary variables of the home context. It is an anachronism and should be forbidden also.
Thank you for the explanation. I'm just curious why it is so difficult to implement a debugger if arguments are assignable? If you need to restart the execution of a method, and so you need to get the initial value of the argument, I understand you cannot find the value anymore in the method context but it is available in the caller context, no? As I never implemented a debugger, I cannot figure out the difficulties.
the args are no longer available; they get moved from the caller context to the callee. If you think about stack frames then what happens is that the slots containing the outgoing arguments are used as the slots for the incoming arguments. So if arguments are assigned to they are indeed lost.
ok, I understand. Thank you for the explanation.
But look at how many methods in the system (or in any system). The proportion of methods/functions/procedures that could be written to assign their arguments is very small so the Smalltalk trade off is a good one.
I agree we don't really loose something. You can always assign arguments to temporary variables and update temporary variables. My point was just: if possible, why don't do it?
It's that tricky trade-off between value and cost. Is it worth it? Does doing it provide as much value as doing what it displaces (opportunity cost). IMO it simply doesn't provide enough value, and there are different priorities in the compiler. But if you disagree implement it your self and then it'll be done.
It looks like "My point was just: if possible, why don't do it?" was misunderstood. I wanted to say: if available for free (no work needed, why forbid it?). You gave a very good reason and I also think that the cost does not worth the value. :) Cheers, Christophe.
On Mon, Mar 24, 2014 at 10:00 AM, Christophe Demarey < Christophe.Demarey@inria.fr> wrote:
Hi Eliot,
Le 20 mars 2014 à 17:04, Eliot Miranda a écrit :
On Thu, Mar 20, 2014 at 2:03 AM, Christophe Demarey < Christophe.Demarey@inria.fr> wrote:
Hi Eliot,
Le 19 mars 2014 à 16:25, Eliot Miranda a écrit :
Hi Christophe,
On Mar 19, 2014, at 1:45 AM, Christophe Demarey < Christophe.Demarey@inria.fr> wrote:
Le 18 mars 2014 à 19:50, Eliot Miranda a écrit :
On Tue, Mar 18, 2014 at 10:10 AM, Christophe Demarey < Christophe.Demarey@inria.fr> wrote:
Why arguments should be read only? They are just temporary variables with an initial value.
Read the blue book. It was a decision of the language designers to forbid assignment to arguments to allow debugging. The assignment to block arguments is a side-effect of the old BlockContext implementation of blocks where block arguments were mapped onto temporary variables of the home context. It is an anachronism and should be forbidden also.
Thank you for the explanation. I'm just curious why it is so difficult to implement a debugger if arguments are assignable? If you need to restart the execution of a method, and so you need to get the initial value of the argument, I understand you cannot find the value anymore in the method context but it is available in the caller context, no? As I never implemented a debugger, I cannot figure out the difficulties.
the args are no longer available; they get moved from the caller context to the callee. If you think about stack frames then what happens is that the slots containing the outgoing arguments are used as the slots for the incoming arguments. So if arguments are assigned to they are indeed lost.
ok, I understand. Thank you for the explanation.
But look at how many methods in the system (or in any system). The proportion of methods/functions/procedures that could be written to assign their arguments is very small so the Smalltalk trade off is a good one.
I agree we don't really loose something. You can always assign arguments to temporary variables and update temporary variables. My point was just: if possible, why don't do it?
It's that tricky trade-off between value and cost. Is it worth it? Does doing it provide as much value as doing what it displaces (opportunity cost). IMO it simply doesn't provide enough value, and there are different priorities in the compiler. But if you disagree implement it your self and then it'll be done.
It looks like "My point was just: if possible, why don't do it?" was misunderstood. I wanted to say: if available for free (no work needed, why forbid it?). You gave a very good reason and I also think that the cost does not worth the value. :)
Agreed. Good discussion. -- best, Eliot
On 18 mars 2014, at 17:02, Clément Bera <bera.clement@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 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?
For methods it is a bug, thanks for noticing. I will check.
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.
On 18.03.2014, at 18:17, Camille Teruel <camille.teruel@gmail.com> wrote:
On 18 mars 2014, at 17:02, Clément Bera <bera.clement@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 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?
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 <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.
2014-03-18 18:31 GMT+01:00 Max Leske <maxleske@gmail.com>:
On 18.03.2014, at 18:17, Camille Teruel <camille.teruel@gmail.com> wrote:
On 18 mars 2014, at 17:02, Clément Bera <bera.clement@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). 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. 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...
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 <nicolaihess@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.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.
2014-03-18 18:47 GMT+01:00 Clément Bera <bera.clement@gmail.com>:
2014-03-18 18:31 GMT+01:00 Max Leske <maxleske@gmail.com>:
On 18.03.2014, at 18:17, Camille Teruel <camille.teruel@gmail.com> wrote:
On 18 mars 2014, at 17:02, Clément Bera <bera.clement@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 <nicolaihess@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.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.
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<https://pharo.fogbugz.com/default.asp?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 <https://pharo.fogbugz.com/default.asp?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
On 18 Mar 2014, at 17:02, Clément Bera <bera.clement@gmail.com> wrote:
Hello,
For blockClosures it is normal, block closure arguments have always been assignable since smalltalk-80.
No this is wrong.
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.
No they should not
So 12419 is not a bug to me, it's a feature.
No this is a bug.
For methods it is a bug, thanks for noticing. I will check.
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.
participants (9)
-
Camille Teruel -
Christophe Demarey -
Clément Bera -
Eliot Miranda -
Igor Stasenko -
Max Leske -
Nicolai Hess -
Nicolas Cellier -
Pharo4Stef