[squeak-dev] Ancient Mantis Report 1554, compiler and global vs
class variables
Nicolas Cellier
nicolas.cellier.aka.nice at gmail.com
Mon Jul 22 15:06:42 UTC 2013
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
More information about the Squeak-dev
mailing list
|