>> 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.

I see what you want. You want that by construction you cannot end up in 
a situation
where you rely on the compiler resolution. This is why I always try not 
to use local and iv
having the same name. I understand that perfectly and at the level of 
instance variables and
local this is good because I never know which one take precedence on 
the other because
iv are closer than local to me :) from an object perspective.

The problem is that willing to have such kind of rules at the level of 
classVariables
then introduce the fact that if I load a package I can break simply 
your system and also
you end up flattening the space and this is not really good especially 
when you do not have
namespace. because if you would have namespace this would be a 
completely different story,
as a programmer I would responsible that my "global" variable do not 
clash with others.



> 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.

But you cannot because we are not in a closed world assumption. You 
cannot
know which names are used. May be we can use prefix (arghhhhhhhhhh) :).

> 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").
You lost me here :)

> 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.

but a rename will not work because another package on this cool 
squeakMap may break
you later.

Stef


> Cheers,
>   - Andreas
>
>