From: "Tim Rowledge" tim@sumeru.stanford.edu
Anthony Hannan ajh18@cornell.edu wrote:
"Peter van Rooijen" squeak@vanrooijen.com wrote:
From: "Anthony Hannan" ajh18@cornell.edu
but he also changed Class>>declare: to no longer raise a notifier when filing-in a class var that shadows another var.
Defining a class variable that shadows another var is neither an error
nor
something that needs to be debugged, so I don't see the reason for
sending
self error:, *at all*.
I would still like to see a notifier because I don't think it is not good style to shadow a global var.
I'd go further; not only is it not good style, it is decidedly dangerous to the understandability of the system.
What exactly do you mean by "it", which you consider so dangerous?
Is it the fact that class variables shadow pool variables shadow global variables (i.e., part of the Smalltalk shared variable scope rules)? Or is it the fact that I am trying to bring Squeak in line with the Smalltalk shared variable scope rules?
Or is it perhaps something else?
Worse yet it makes a possibility that two bits of code that look very similar can refer to quite different variables.
That is indeed how Smalltalk works, yes.
Even worse, the time-order of compiling methods could result in some refering to the global and some to the classvariable.
No, it can't, unless there are bugs in the implementation (which currently probably do exist because it seems that this has not been given attention before). The scope rules are unambiguous. So, what you are saying is not a complaint against the scope rules.
All in all, a terribly bad thing.
In your view, is it so terribly bad that you would also want to prohibit people from defining globals with the same name as an existing class variable or pool variable?
Cheers,
Peter van Rooijen Amsterdam
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- If she was any dumber, she'd be a green plant.