[squeak-dev] Shadowing "reserved" variables

Frank Shearar frank.shearar at gmail.com
Fri Jul 19 02:15:06 UTC 2019


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, <
squeak-dev at lists.squeakfoundation.org> 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 <
> nicolas.cellier.aka.nice at gmail.com> 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 <asqueaker at gmail.com> a
> écrit :
>
>> Wow.  We should disallow that.  Those words are reserved.
>>
>> On Wed, Jul 17, 2019 at 5:52 AM Levente Uzonyi <leves at caesar.elte.hu>
>> 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
>>>
>>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190718/954953c5/attachment.html>


More information about the Squeak-dev mailing list