Shadowing "reserved" variables
Locked
Shadowing "reserved" variables
 
|
Hi All,
You can currently evaluate the following: [ :self :thisContext | | nil super true false | nil := 1. super := 2. true := 3. false := 4. self + thisContext = (nil + super + true + false) ] value: 4 value: 6 Is this the expected behavior or should we disallow such oddities? Levente |
Re: Shadowing "reserved" variables
|
|
The ANSI Standard in section 3.4.2 Method Definition, states the following:
"It is erroneous if the same identifier is used for more than one <method argument> in an individual
<method definition>. It is erroneous if any of the reserved identifiers ('nil', 'true', 'false', 'self', and
'super') is used as a <method argument>. It is erroneous if the same identifier is used as a
<method argument> of a <method definition> and also appears in the method's <temporary
variable list>. An identifier that is used as a <method argument> is called a method argument
name." The sections which define the scopes for instances, classes, and pools also prohibit the used of the five reserved words. By extension, we may infer that shadowing pseudo-variables such as thisContext should in all likelihood be disallowed as well. John
|
Re: Shadowing "reserved" variables
|
|
In reply to this post by Levente Uzonyi
> On 2019-07-17, at 3:51 AM, Levente Uzonyi <[hidden email]> wrote: > > Hi All, > > You can currently evaluate the following: > > [ :self :thisContext | > | nil super true false | > nil := 1. > super := 2. > true := 3. > false := 4. > self + thisContext = (nil + super + true + false) ] value: 4 value: 6 > > Is this the expected behavior or should we disallow such oddities? I think I'd quite like to see that prevented. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: BOZO: Use Multics operating system |
Re: Shadowing "reserved" variables
|
|
>> You can currently evaluate the following:
>> >> [ :self :thisContext | >> | nil super true false | >> nil := 1. >> super := 2. >> true := 3. >> false := 4. >> self + thisContext = (nil + super + true + false) ] value: 4 value: 6 >> >> Is this the expected behavior or should we disallow such oddities? > > I think I'd quite like to see that prevented. Indeed. Stef |
Re: Shadowing "reserved" variables
|
|
In reply to this post by Levente Uzonyi
Wow. We should disallow that. Those words are reserved. On Wed, Jul 17, 2019 at 5:52 AM Levente Uzonyi <[hidden email]> wrote: Hi All, |
Re: Shadowing "reserved" variables
|
|
Is it really a problem? Did the system horribly break? IMO this should just be not recommended. Le ven. 19 juil. 2019 à 00:39, Chris Muller <[hidden email]> a écrit :
|
Re: Shadowing "reserved" variables
|
|
It is by definition erroneous. It is counter to the definition of the standard language. That is a problem that should be fixed.
|
Re: Shadowing "reserved" variables
|
|
The snippet from the standard says that it is illegal to use these identifiers as method arguments. The example uses block arguments. Now maybe a reasonable person would assume that argument names, regardless of whether method or block (especially if one views blocks as anonymous methods), come from the same set, and maybe it seems like a terrible idea to allow this kind of shadowing, but I don't see the current behaviour as incompatible with the standard snippet. So sure, forbid such shadowing because it's terrible, but I don't see it being ILLEGAL. frank On Thu., Jul. 18, 2019, 18:26 JOHN SARKELA via Squeak-dev, <[hidden email]> wrote:
|
Re: Shadowing "reserved" variables
|
Shadowing those reserved variables seems to be a nice property that supports (crazy) language experiments. We shouldn't make use of it in Trunk, though. +1 for adding a preference to raise a Warning (or Error) if somebody tries that -1 for prohibiting that in Squeak's default parser all the time Best, Marcel
|
Re: Shadowing "reserved" variables
|
|
Could we possibly let standard Smalltalk-80 be the default choice, and
"crazy" be the optional choice that "experimenters" would explicitly invoke? That way, we don't even need a Warning... - Chris On Fri, Jul 19, 2019 at 12:40 AM Marcel Taeumel <[hidden email]> wrote: > > Shadowing those reserved variables seems to be a nice property that supports (crazy) language experiments. We shouldn't make use of it in Trunk, though. > > +1 for adding a preference to raise a Warning (or Error) if somebody tries that > -1 for prohibiting that in Squeak's default parser all the time > > Best, > Marcel > > Am 19.07.2019 04:15:28 schrieb Frank Shearar <[hidden email]>: > > The snippet from the standard says that it is illegal to use these identifiers as method arguments. The example uses block arguments. > > Now maybe a reasonable person would assume that argument names, regardless of whether method or block (especially if one views blocks as anonymous methods), come from the same set, and maybe it seems like a terrible idea to allow this kind of shadowing, but I don't see the current behaviour as incompatible with the standard snippet. > > So sure, forbid such shadowing because it's terrible, but I don't see it being ILLEGAL. > > frank > > On Thu., Jul. 18, 2019, 18:26 JOHN SARKELA via Squeak-dev, <[hidden email]> wrote: >> >> It is by definition erroneous. It is counter to the definition of the standard language. That is a problem that should be fixed. >> >> On Jul 18, 2019, at 7:53 PM, Nicolas Cellier <[hidden email]> wrote: >> >> Is it really a problem? >> Did the system horribly break? >> IMO this should just be not recommended. >> >> Le ven. 19 juil. 2019 à 00:39, Chris Muller <[hidden email]> a écrit : >>> >>> Wow. We should disallow that. Those words are reserved. >>> >>> On Wed, Jul 17, 2019 at 5:52 AM Levente Uzonyi <[hidden email]> wrote: >>>> >>>> Hi All, >>>> >>>> You can currently evaluate the following: >>>> >>>> [ :self :thisContext | >>>> | nil super true false | >>>> nil := 1. >>>> super := 2. >>>> true := 3. >>>> false := 4. >>>> self + thisContext = (nil + super + true + false) ] value: 4 value: 6 >>>> >>>> Is this the expected behavior or should we disallow such oddities? >>>> >>>> Levente >>>> >>> >> >> >> |
Re: Shadowing "reserved" variables
|
|
Sure, there is always the option to provide a custom parser. I was just thinking about how just overriding "self" is simpler than figuring out how to provide a custom parser for such things. So, even with a Warning, the default should be to throw that Warning. I am just not in favor of hard-coding that rule into Parser. :-) Best, Marcel
|
Re: Shadowing "reserved" variables
|
|
In reply to this post by Frank Shearar-3
Standard Section 3.4.4
"It is erroneous if the same identifier is used for more than one <block argument> of a individual <block constructor>. It is erroneous for any one of the reserved identifiers ('nil', 'true', 'false', 'self' and 'super') to be used as a <block argument>. It is erroneous if the same identifier is used both as a <block argument> and also appears in the <temporaries> of a single <block constructor>. An identifier that is used as a <block argument> is called a block argument name. An identifier that appears in the <temporaries> of a <block constructor> is called a block temporary variable name." According to the standard it is *erroneous* to shadow these reserved words in *any* scope.
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |