Re: [Pharo-project] About the scope of classVariables

[Stéphane Ducasse]

I'm still wking up (yes at 10h30) I'm not sure that I fully got what you said about shadowing. I think that lexical scope is important and we should have it. Variables closer to me should take precedence over farther ones. My point is the following: I have CZLAtexGenerator and it defined a classVariable or use a CZPool to encode Editor = the guy editing a book I defined a class Variable Editor. I do not want to be forced to write CZEditor. so in the code of CZLatexGenerator - I should be able to refer to the class variable Editor (and I should not care about the fact that there is or not an Editor class elsewhere). Now if I load my package in a system that contain already Editor (for graphical stuff). I do not want my code to refer to it. It should refer to my ClassVariable. Now that I get a warning when I shadow Editor why not but I want to get my variable taking precedence as in any decent language. Stef 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. Lukas -- Lukas Renggli www.lukas-renggli.ch