Stef asked urged me to look into this discussion. I am trying to 
comply, but I really have not a lot of time, so I did not check the 
start of this thread on the Squeak mailing list (just the ones on the 
KCP mailing list).

 From these mails (and without really understanding who is proposing 
exactly which scoping/visibility rules) I notice that two separate 
discussions are being held at the same time: (1) what 
scoping/visibility rules do we want? (2) what happens when the system 
changes (due to editing or file-in or ...). Of course these issues are 
related, but I'd prefer to have them discussed a bit more cleanly for 
my sake of understanding :-)

So who is supporting which scoping/visibility?
Quickly thinking about it, it seems that I prefer the same mechanism as 
it exists for instance variables/temporary variables, where the shared 
variable is treated as the temporary variable (and the global variables 
are treated as instance variables). Why? Well, because a class contains 
instance variables and methods, and these methods can contain temporary 
variables. Similarly, the system contains global variables, and the 
classes amongst those can contain shared variables.

So, regarding what happens when conflicts occur (because of name 
clashes due to editing or filing-in): I'd do the same as for instance 
variables/temporary variables. If a global variable changes to a name 
used by a class variable, the class variable shadows until we try to 
edit someplace where it is used. Otherwise we cannot shadow it to start 
with. So, in short, shadowing is only used to resolve conflicts as a 
result of changes, and not as a possible mechanism (I do believe that 
this is important).


On Monday, Oct 13, 2003, at 23:18 Europe/Zurich, Andreas Raab wrote:

>>> 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.
>
> Of course you can! All that's required is to be explicit. For example:
> 	Smalltalk at: #Global.
> 	self class classPool at: #Global.
> 	SomeSharedPool at: #Global.
> are all very explicit (and admittedly very ugly ;) But that's totally
> unrelated to any "closed world assumption". I would much rather use 
> one of
> the above instead of having Symbol to refer to a font. And it would 
> give me
> a real incentive for fixing the name conflict.
>
>> You cannot know which names are used.
>
> You don't have to (see below).
>
>>> 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 :)
>
> Looks like it. What I was saying is that when someone starts to modify 
> a
> method with a potentially shadowed global the person should be told in 
> No
> Unclear Terms that this global is not what it looks like. I think that 
> this
> would solve 90% of the interesting situations simply because if you 
> expect
> some reference to be a global (rather than the shadowing object) 
> probably
> the first thing you'll do is to print or inspect it (this is what I 
> did with
> the example posted by Peter). If the system kicks in and tells you that
> there is some shadowing going on it means that you are immediately 
> aware of
> the fact that things may not be what they seem.
>
> It's only if the system silently compiles stuff (because the compiler 
> can
> figure it out) but the user's got no idea about the situation that 
> things
> get ugly.
>
>>> 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.
>
> Which is a) no better or worse than any other change to a package (do 
> you
> expect packages to be unchangable?) and b) has a very small 
> probability as
> we are talking about shadowed globals which mostly come from class 
> variables
> so you would have to both, make a subclass and use that class var in 
> order
> to be affected. Seems like a VERY reasonable tradeoff to me.
>
> Cheers,
>   - Andreas
>
>
>
Roel Wuyts                                                              
   DeComp
roel.wuyts at ulb.ac.be                               Université Libre de 
Bruxelles
http://homepages.ulb.ac.be/~rowuyts/                                    
Belgique
Board Member of the European Smalltalk User Group: www.esug.org