2011/10/7 Levente Uzonyi <leves@elte.hu>:
On Fri, 7 Oct 2011, Igor Stasenko wrote:
On 7 October 2011 11:16, Frank Shearar <frank.shearar@gmail.com> wrote:
On 7 October 2011 08:42, Lukas Renggli <renggli@gmail.com> 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.
I must be missing something. I thought Stéphane was talking about something like
Object subclass: #Foo     instanceVariableNames: ''     classVariableNames: 'OrderedCollection'     poolDictionaries: ''     category: 'BalloonTests-Fills'
bar     OrderedCollection := Array.     (OrderedCollection with: 1) add: 1
but "Foo new bar" raises the expected "Error: This message is not appropriate for this object".
What am I missing?
everything is ok: an #add message is not appropriate for Array.
Frank tried to point out that shadowing a global with a class variable actually works.
yes. So I did not get Stef's problem. Luc
Levente
frank
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Best regards, Igor Stasenko.