<div dir="ltr"><div><div>So we could fix it like this:<br><br>bindingOf: varName environment: anEnvironment<br> "Answer the binding of some variable resolved in the scope of the receiver"<br> | aSymbol binding |<br>
aSymbol := varName asSymbol.<br><br> "First look in classVar dictionary of the whole hierarchy"<br> (self classThatDefinesClassVariable: varName) ifNotNilDo: <br>
[:x | ^x classPool bindingOf: varNameSymbol].<br><br> "Next look in shared pools."<br> self sharedPools do:[:pool | <br> binding := pool bindingOf: aSymbol.<br> binding ifNotNil:[^binding].<br>
].<br><br> "Next look in declared environment."<br> binding := anEnvironment bindingOf: aSymbol.<br> binding ifNotNil:[^binding].<br><br> "Finally look higher up the superclass chain and fail at the end."<br>
superclass == nil<br> ifTrue: [^ nil]<br> ifFalse: [^ superclass bindingOf: aSymbol].<br><br>However, I wonder if it is a super idea to ask for superclass bindingOf:<br></div><div>- First, the will start the classVar look-up of whole hierarchy (minus one) again.<br>
</div><div>- Second, imagine that class A is defined in environment E1, and class B is a subclass of A defined in a specific environment E2.<br></div></div>Shall B see all bindings of E1?<br><div class="gmail_extra"><br></div>
<div class="gmail_extra">I don't think so, so I'd rather remove last statement. What do you think?<br></div><div class="gmail_extra">There is also the sharedPools problem, is a SharedPool visible by all subclasses?<br>
<br></div><div class="gmail_extra">Nicolas<br></div><div class="gmail_extra"><br><div class="gmail_quote">2013/7/22 Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Basic correction is just a matter of rewritting bindingOf: (now moved to bindingOf:environment:)<br>
</div>Then there are UI corrections that probably need deeper review.<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">2013/7/22 tim Rowledge <span dir="ltr"><<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
On 21-07-2013, at 7:31 PM, Ken Causey <<a href="mailto:ken@kencausey.com" target="_blank">ken@kencausey.com</a>> wrote:<br>
><br>
><br>
> 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.<br>
<br>
</div>Hindsight can be a wonderful thing… I'm not sure any of us thought there would be Squeak to still worry about by now.<br>
<div><br>
><br>
> 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.<br>
<br>
</div>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.<br>
<div><br>
<br>
tim<br>
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" target="_blank">http://www.rowledge.org/tim</a><br>
</div>Oxymorons: Software documentation<br>
<br>
<br>
<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>