Keep in mind that this will be quite a complicated change, as it has many consequences across the whole system. For example, if you allow shadowing of globals with class variables you need to start to recompile/patch some methods in the class hierarchy with any class variable change. Also you need to revise the handling of obsolete associations, because that will become more complicated with the possibility of having the same name on different levels.
Lukas On 7 October 2011 09:57, Stéphane Ducasse <[email protected]> wrote: > > On Oct 7, 2011, at 9:42 AM, Lukas Renggli wrote: > >>> I do not understand why classVariables cannot shadow globals and take >>> precedence over them. >>> When I define a classVariable the resolution should take classVariable over >>> global. >> >> Any kind of shadowing is disallowed in Smalltalk. >> >> I think this is part of the language design is quite broken and a >> rather static approach that is very strange in a dynamic language like >> Smalltalk. Not even Java has these kind of static restrictions. >> >>> Now what will happen if I define classVariable with a name that is ok in my >>> current image but will be present >>> in the future in the image I will load my code! >> >> Yes, this is the current semantics. The possibility to shadow globals >> would be very useful to replace globals in the context of a class >> hierarchy. I suggested already many years ago to replace all shadowing >> errors on all levels (temps, arguments, inst vars, class vars, pool >> vars, globals) with compiler warnings. > > > We should fix that. > And start with ClassVariable and Pool lookup. It should take precedence over > globals. > Now I have to prefix all my classVariables and this is bad (it gives a bad > feeling). > > > > >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > -- Lukas Renggli www.lukas-renggli.ch
