"Andreas Raab" <andreas.raab at gmx.de> wrote:
> 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.

Religiously, I'm very used to having shadowing.  When I wrote down a
semantics for Smalltalk, it never occured to me *not* to allow
shadowing.  It's just They Way that lexically scoped languages work.

But there are two big problems to supporting it properly in Squeak:

	1. As a few people have pointed out, it is confusing.  The "Symbol"
example is especially illuminating.

	2. We would surely want syntax to allow access variables from outer
scopes, and Smalltalk doesn't have it.  This is an irritating addition
to the concise syntax of Smalltalk, and there's a slippery slope from
there that makes it even worse:  People might start explicitly scoping
their variable accesses just in case some other programmer shadows the
variable in the future.  Yuck!!   Although, I guess super-nice tools
could add the scoping automatically when the variable reference would
have changed; even then, it's a significant amount of programming.

Further, I can only think of one good reason to allow shadowing: to let
people load valid code from disk.  This is a good reason, because if we
disallow such loading, then it is a pain to fix the code and get rid of
the shadowing!  But there are no other ones.  The one reason that
crossed my mind at all is to support making subclasses of an opaque
framework class.  The idea would be that you can name your variables
however you like, and you will not care what variables the superclass
has.  However, this breaks down anyway, because this exact issue is
already present for method names.  If we can't solve the problem as a
whole, then it seems unimportant to solve it halfway.  The way things
stand, you simply must do a brief skimming of any class you want to
inherit from, and supporting shadowing wouldn't help.


On the whole, it sounds like a good compromise is to have the compiler
support shadowing, but for the interactive tools to act like Andreas
describes and strongly sway programmers away from it.  Additionally, it
would be very nice if there were a world menu somewhere that finds all
shadowed variables in the current image, so that programmers can check
up on things every once in a while.



-Lex