From: "Tim Rowledge" <tim at sumeru.stanford.edu>
> "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.

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