Hi Stef,

Looks like we agree on disagreeing. Nothing wrong with that. But it still
seems you're not understanding what I'm talking about, namely explicitness
in referencing variables which are "potentially ambiguous". Let's do a
little thought experiment here: Let's assume Squeak would have a "scope
operator" and let's call this operator (in lack of a better one) simply
"::". Now, what I would _want_ you to use is essentially an explicit scope
if there is a shadowed (e.g., "multiply defined") implicit global in a
method which you interactively modify. So if you load the Symbol font and
then hack ParagraphEditor you would have to state:

	Smalltalk::Symbol.     "to refer to the Symbol class"
	TextConstants::Symbol. "to refer to the Symbol font"

in order to be explicit about what you mean. Note that the above is really
only syntactic sugar on the various ugly forms that I've used in the
previous message. Also - contrary to what Ingo was implying - there is no
_need_ to rename the variable (the ugly forms are simply more "motivating"
to resolve the ambiguity by renaming). And you can always send changes that
contain "explicitly scoped" references to someone who uses the implicit
scope for referencing a variable (assuming that the implicit scope is the
same as the explicit one; e.g., referencing TextConstants::Symbol on a
system not having the Symbol font loaded would - rightfully - resolve to an
undeclared variable). And it completely avoids the problem of someone
accidentally using the "wrong" scope. Shadowing is left exclusively for the
compiler (who knows what to do with it) but not for the user to worry about
;-)

Does this make it a little clearer what I'm really after?

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of ducasse
> Sent: Thursday, October 16, 2003 10:24 PM
> To: The general-purpose Squeak developers list
> Subject: Re: [BUG]UndefinedObject(Object)>>error:
> 
> 
> I think that you are wrong. temp shadowing in the same that class 
> shadowing because they do not play the same
> role. Now I think that nathanael did a really good job at explaining 
> the pros and cons to each approach. So I will stop to argue because 
> this leads nowhere. Now we know all the points and not having class 
> shadowing  breaks
> the idea of distributed development. I like the scenario of Ingo and 
> its two cents were rigth.
> 
> Feel free not to believe us. One of my favorite and sharp 
> professor was 
> used to say: "if this is what you believe"
> 
> Stef
> 
> 
> On Jeudi, oct 16, 2003, at 22:11 Europe/Zurich, Andreas Raab wrote:
> 
> >> Can it be that you guys are misunderstanding each other?
> >
> > Not likely ;-) I see perfectly well the arguments for 
> shadowing but it 
> > seems
> > to me most people who arguing in favour of shadowing have 
> never been 
> > bitten
> > by it. So I'd recommend that those people really load the 
> Win32Fonts, 
> > get
> > the Symbol font and start hacking ParagraphEditor. That'll 
> cure them 
> > faster
> > than anything ;-)
> >
> >> So, therefore I suggested to
> >>
> >> a) disallow interactively creating class variables that 
> shadow globals
> >> b) warn if a conflict occurs non-interactively (e.g., 
> while loading a
> >> package)
> >> c) change the semantics of Squeak (i.e., make a trivial fix to the
> >> compiler) so that even in the intermediate state (i.e.,
> >> between the time when the conflict occurs and the time when
> >> it is resolved), everything works fine.
> >>
> >> Could you all live with that?
> >
> > I don't even like the idea of referencing the shadowed globals 
> > interactively
> > without being explicit about what you mean. What I am 
> arguing for is 
> > simply
> > the same rules that we have already in place for temps.
> >
> > Cheers,
> >   - Andreas
> >
> >
> >
> 
>