[BUG]UndefinedObject(Object)>>error:

Richard A. O'Keefe ok at cs.otago.ac.nz
Thu Oct 16 23:57:59 UTC 2003


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



More information about the Squeak-dev mailing list