On 11.01.2013, at 03:06, Frank Shearar <
[hidden email]> wrote:
> On 10 January 2013 00:16, <
[hidden email]> 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 -
Locked
