Hi Stef,

> originally I was not interested by the thread (for other personal 
> reasons (people that attended esug know why)). But I have the 
> impression that if the interpretation of a classVariable is only 
> visible inside the class and class of the class (plus children) then 
> peter is right.

Oh, sure he is. Given the rules we have today, this is a bug. But Tim's
argument wasn't that the current behavior isn't buggy it was that allowing
for this kind of shadowing is bound to introduce a lot of confusion in
understanding the system. And that's been my point too.

To give another illustrating example: TextConstants contains besides the
constants also all of the text styles. Now, once upon a time I loaded the
"Symbol" font in Windows. And then I happened to touch a a method (don't
remember where) in a place that imported TextConstants and had a reference
to "Symbol" in it. Can you guess what happened?

> A classVariable should not be touched if you define a class that by 
> accident as the same name else all your code can break and you lose
> the locality of the definition.

I agree on this. However, my understanding is that once you have that kind
of shadowing your code is no longer understandable as it is unclear what you
_mean_ when you refer to the shadowed variable. A similar situation occurs
when you look at temp vs. inst var name shadowing (though here the situation
is easier since you can see the definition of temps). And while we allow you
to change a class definition so that a temp shadows an iVar we do NOT allow
you to interactively accept any such method. IOW, as soon as you touch a
method with a shadowed temp you are _forced_ to rename it to resolve the
conflict between those names.

Something alike would be my goal here. Again, the point is not that compiler
can't make sense of it (it sure can). It's that the user quite possibly
can't make any sense of it.

> Imagine in presence of package without namespace.
> The current semantics makes the following:
> 	- I checked while defining my package that there is no 
> class with name X and I then use my classVariable X
> 	- I published it on Squeak map (perfect sunny day today)
> 	- then I load another package that by accident define a 
> class or another classVariable with the same name
> 	and my code break (a black day where sleeping would 
> have been better).
> 
> Is it really that that you are implying?

No, it's not. But we should try Really Hard (tm) to encourage you to fix
those conflicts at the earliest time possible. You may be able to load that
package containing the shadowed global, but whether you should be allowed to
interactively change it without resolving the conflict is quite a different
matter (and really what I meant by "preventing it at all costs").

And note that if we force you to fix the problem the first time you may be
introducing one of these confusions it means that your scope is still unique
- e.g., it is clear that all existing references go to the shadowed variable
and it is simple to just do a global rename.

Cheers,
  - Andreas