[BUG]UndefinedObject(Object)>>error:

Andreas Raab andreas.raab at gmx.de
Mon Oct 13 21:18:09 UTC 2003


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



More information about the Squeak-dev mailing list