[FIX] ClassVarsFix-petervr (was: Shared variablesbinding/lookupbug)

Tim Rowledge tim at sumeru.stanford.edu
Sun Oct 12 21:03:22 UTC 2003


"Peter van Rooijen" <squeak at 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 at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Disc space, the final frontier!



More information about the Squeak-dev mailing list