I don't care a fig what any standard says, it's foolish.
+1
- Andreas
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Tim Rowledge Sent: Sunday, October 12, 2003 11:03 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: [FIX] ClassVarsFix-petervr (was: Sharedvariablesbinding/lookupbug)
"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.
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.
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?
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.
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.
I don't care a fig what any standard says, it's foolish.
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Disc space, the final frontier!