[Pharo-project] About the scope of classVariables
Hi guys 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. Right now I have to prefix my classVariable to be able to define them. 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! I have to check what paolo did in GNU because he changed something. I think that there is something really broken or I'm totally stupid. Stef
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
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
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 <stephane.ducasse@inria.fr> 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
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? frank
Lukas
-- Lukas Renggli www.lukas-renggli.ch
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
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Best regards, Igor Stasenko.
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. Levente
frank
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Best regards, Igor Stasenko.
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.
Hi levente
Frank tried to point out that shadowing a global with a class variable actually works.
When I try Object subclass: #Plop instanceVariableNames: '' classVariableNames: 'OrderedCollection Editor' poolDictionaries: '' category: 'Citezen-Stef-Scripts' I get a duplicate warning for Editor. Same with OrderedCollection. When I proceed it indeed works (which is good) Now my scenario was that I was using the browser to define classVariable interactively and I could not for Editor. So at least this is a good news. Stef
Apparently I identified a bug I have a sharedPool SharedPool subclass: #CZPool instanceVariableNames: '' classVariableNames: 'Author BookTitle Chapter Editor Institution Journal Note Number Pages Publisher RequiredFields School Series Title Volume Year uthor' poolDictionaries: '' category: 'Citezen-Model' and on the class side of a pool user class Object subclass: #Flop instanceVariableNames: 'key value' classVariableNames: '' poolDictionaries: 'CZPool' category: 'Citezen-Model' If I have Flop class>> foo ^ Author it will return the SharedPool value. Now if I define the method in a subclass Flop class>> foo ^ Author return the Author global class Now I understand I got a problem.
participants (6)
-
Frank Shearar -
Igor Stasenko -
Levente Uzonyi -
Luc Fabresse -
Lukas Renggli -
Stéphane Ducasse