On Fri, 7 Oct 2011, Igor Stasenko wrote:
On 7 October 2011 11:16, Frank Shearar <[email protected]> wrote:
On 7 October 2011 08:42, Lukas Renggli <[email protected]> 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.
Levente
frank
Lukas
--
Lukas Renggli
www.lukas-renggli.ch
--
Best regards,
Igor Stasenko.
