We should meet more often. :). I really hate this stupid medium we use 
to communicate.
We should have SmalltalkParty in Germany: marcus, markus any taker?! We 
could have two Smalltalk
events per year in Europe without any problem. I know that claus was 
planning to organise something may
be you should contact him.
And you should try to come to ESUG (I know we tried to change the dates 
but failed for
money reason again this year).

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

I see. For me the key point is that load package X should not break my 
code.
Because I was self contained code (let us dream).

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

I try to understand thanks for your patience. I do not understand why
scoping rules do not work with you (even if I agree that I do not like 
shadowing).
And I have the impression that you are not talking about Smalltalk but 
Smalltalk++. :)

Then the question I have is do we stay in Smalltalk or in another 
version, I have
no problem moving but in that case the discussion is something else. For
example with the classboxes we were discussing that we could get rid of 
classVar
and Pool and just have classBox variables. But this is another 
Smalltalk.

Stef

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