I agree


On Vendredi, oct 17, 2003, at 01:57 Europe/Zurich, Richard A. O'Keefe 
wrote:

> =?iso-8859-1?Q?Nathanael_Sch=E4rli?= <n.schaerli at gmx.net> wrote:
> 	1) It is not possible to create a class with a class variable that
> 	shadows a global. This is exactly the same as it is not possible to
> 	create a temp var with the same name as an inst. var.
> 	
> I hate this sort of bondage-and-discipline approach, because it never 
> scales
> well.  Consider the following story:
>
>     Miss X writes a class C in Squeak 3.7.  It follows every known 
> style
>     rule and works flawlessly.  It has a class variable Seeds.  She 
> saves
>     it in C.st
>
>     Along comes Squeak 3.8.  Miss X tries to load C.st.  Now she is
>     told "you EVIL NAUGHTY WICKED programmer you; you DARE you do
>     anything like that in front of an innocent computer?"  Why?  
> Because
>     Squeak 3.8 now has a Seeds global variable.
>
> This can also lead to situations where class X can be loaded before
> class Y but not after.
>
> This is not an entirely hypothetical situation; I don't know most of
> the classes in Squeak, and each release there are more I don't know.
> It's especially likely to be a problem for someone writing a class 
> using
> the development version and someone else trying to load it into the 
> full
> version.  In fact, it was precisely a 
> developed=in-one-context-and-loaded-
> in-another problem which started this whole thread.
>
> The real answer doesn't lie in punishing the victim, but in controlling
> the global namespace better, which was of course the point of the 
> Modules
> attempt.
>
> 	I assume that everyone agrees on 1)
>
> NO.  *Warnings* yes.  But it is really quite unacceptable to stop 
> someone
> writing or loading a perfectly well defined class just because of some
> obscure addition to an uncontrolled global namespace.
>
> In precisely the same way, if I have a method with an argument or 
> temporary
> called "x", and later someone adds an instance variable named "x", that
> should by all means raise a warning, but on no account should the 
> method
> be broken.  And this kind of shadowing should be tolerated as a 
> temporary
> stepping-stone in a refactoring.  If I push a method using an argument 
> or
> temporary "x" down from a parent class that doesn't have an instance 
> variable
> x to a child class that does, I should be allowed to do so and THEN 
> rename
> the variable.
>