On 11.01.2013, at 03:06, Frank Shearar <frank.shearar at gmail.com> wrote:

> On 10 January 2013 00:16,  <commits at source.squeak.org> wrote:
>> Bert Freudenberg uploaded a new version of Environments to project The Trunk:
>> http://source.squeak.org/trunk/Environments-bf.12.mcz
>> 
>> ==================== Summary ====================
>> 
>> Name: Environments-bf.12
>> Author: bf
>> Time: 9 January 2013, 4:16:32.604 pm
>> UUID: 6c062187-89cf-4350-b0f3-28c0ad57fc37
>> Ancestors: Environments-fbs.11
>> 
>> Environment>>bindingOf: must not answer undeclared bindings. E.g., in my case a binding in undeclared shadowed a perfectly fine class variable higher up in the class hierarchy.
>> 
>> =============== Diff against Environments-fbs.11 ===============
>> 
>> Item was changed:
>>  ----- Method: Environment>>bindingOf:ifAbsent: (in category 'binding') -----
>>  bindingOf: aSymbol ifAbsent: aBlock
>>        lookup do:
>>                [:dict |
>>                (dict includesKey: aSymbol) ifTrue:
>>                        [^ dict associationAt: aSymbol]].
>> +       ^ aBlock value!
>> -       ^ undeclared associationAt: aSymbol ifAbsent: aBlock!
> 
> I'm a bit slow; I'd love to see a pair of tests for this!
> 
> frank

Well, go ahead and write one :)

The method in question is Class>>bindingOf:environment:. It relies on Environment>>bindingOf: answering nil if there is no actual binding. Only then it will look up the super class chain.

So, *obviously* Environment>>bindingOf: must not answer from Undeclared.

Independent of that, I do wonder why Class>>bindingOf:environment: looks into the environment first, however. This means that a global variable would shadow an inherited class variable or pool variable, which is against my intuition of how scoping works. Does anyone know why this would be intended?

- Bert -