From: "Tim Rowledge" tim@sumeru.stanford.edu
"Peter van Rooijen" squeak@vanrooijen.com wrote:
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)?
Yes. I think it's a really stupid thing to do. It doesn't matter if it is technically within any 'standard rules'. It's just plain dumb t do it.
Tim, let me get this straight: Before you define or rename a class you always check if any existing class has a class variable, or any existing pool dictionary has a pool variable with the name you are planning to use for your class. Correct? If the name is already in use in any of those places, you either change it there, or choose another name for your class. Right? After all, you wouldn't do a thing that is 'plain dumb to do'.
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.
You don't need to lecture me on how Smalltalk works. I've been making it professionally for twenty years.
You are correct, I don't need to lecture you on how Smalltalk works. It also goes without saying that since you have been 'making it professionally for twenty years', your judgments about it are much more valuable than whatever opinion I might have about it.
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.
Compile a method referring to a Foo global. Add a class variable Foo to the same class. (Squeak objects to this, I'm happy to see.) Compile another method referring to 'Foo'.
What do you expect to be the result?
I'm not sure I see what you're getting at, since this does not support your case at all. If both methods are in the same class, both occurrences of Foo refer to the class variable. What is your point?
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?
Until and unless there is a clearly visible way to differentiate them, yes I would like to prevent it.
Should we be expecting a proposed enhancement from you for this?
Consider another situation:- Class A has a method referring to Foo, a global. Class B, a subclass of A, adds a class variable Foo. A method in B refers to Foo, which clearly you claim binds to the class variable. It also sends a message which resolves to the method in A which refers to Foo the global.
Now try to make any internal sense of this when you have to debug or refactor this code. Yes, I'm sure that a compiler can be made to cope with it but our brains are not compilers (and I don't care what the Forth guys claim) and I feel pretty sure such code would present a major cognitive clash.
Tim, I understand your example and I don't disagree that there is a potential for confusion. But this is just how Smalltalk is constructed. Classes are namespaces for their descendents. That Squeak hasn't correctly implemented this part of what Smalltalk is, does nothing to change this.
If you don't want to have to keep track of shared variable shadowing, try not to use duplicate names in your own code. You can't prevent shadowing from happening, since you don't control what globals someone else may define, but at least you can try and avoid adding to your own confusion.
But would you really have others prevented from using a legitimate, well-defined, Smalltalk construct, because you fear 'a major cognitive clash', because 'our brains are not compilers'?
I don't care a fig what any standard says, it's foolish.
Apparently, you would.
In any case, I have not become aware of any major cognitive clash in the user communities of any of the Smalltalk dialects that do implement shared variable shadowing correctly.
Perhaps someone with more than 20 years of professionally making Smalltalk can shine their light on the issue?
Cheers,
Peter van Rooijen Amsterdam
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Disc space, the final frontier!