So we could fix it like this:

bindingOf: varName environment: anEnvironment
    "Answer the binding of some variable resolved in the scope of the
receiver"
    | aSymbol binding |
    aSymbol := varName asSymbol.

    "First look in classVar dictionary of the whole hierarchy"
    (self classThatDefinesClassVariable: varName) ifNotNilDo:
        [:x | ^x classPool bindingOf: varNameSymbol].

    "Next look in shared pools."
    self sharedPools do:[:pool |
        binding := pool bindingOf: aSymbol.
        binding ifNotNil:[^binding].
    ].

    "Next look in declared environment."
    binding := anEnvironment bindingOf: aSymbol.
    binding ifNotNil:[^binding].

    "Finally look higher up the superclass chain and fail at the end."
    superclass == nil
        ifTrue: [^ nil]
        ifFalse: [^ superclass bindingOf: aSymbol].

However, I wonder if it is a super idea to ask for superclass bindingOf:
- First, the will start the classVar look-up of whole hierarchy (minus one)
again.
- Second, imagine that class A is defined in environment E1, and class B is
a subclass of A defined in a specific environment E2.
Shall B see all bindings of E1?

I don't think so, so I'd rather remove last statement. What do you think?
There is also the sharedPools problem, is a SharedPool visible by all
subclasses?

Nicolas

2013/7/22 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>

> Basic correction is just a matter of rewritting bindingOf: (now moved to
> bindingOf:environment:)
> Then there are UI corrections that probably need deeper review.
>
>
> 2013/7/22 tim Rowledge <tim at rowledge.org>
>
>>
>> On 21-07-2013, at 7:31 PM, Ken Causey <ken at kencausey.com> wrote:
>> >
>> >
>> > Yes, if I had it to do over again and realized that it would be years
>> before issues like these would be resolved, well then again there were
>> signs of that even then.  In any case, I should have been more explicit
>> about specifically what tests were failing for me.
>>
>> Hindsight can be a wonderful thing… I'm not sure any of us thought there
>> would be Squeak to still worry about by now.
>>
>> >
>> > Tim: Are you saying that both before and after the [FIX] is loaded the
>> same 8 tests fail?  Well, given the time that has passed the provided tests
>> may be more valuable than the proposed fix at this point.
>>
>> Given the amount of changes to the compiler since then and the decided
>> lack of my compiler knowledge, I didn't feel safe to try loading it. The
>> tests seemed to load ok, which was nice.
>>
>>
>> tim
>> --
>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>> Oxymorons: Software documentation
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130722/8ea61a7e/attachment.htm