On Jeudi, oct 16, 2003, at 19:00 Europe/Zurich, Andreas Raab wrote:

>> In all other scenarios, the shadowing is helpful.
>
> Sorry, but your entire argumentation is bogus here. Shadowing is 
> extremely
> problematic for someone else to understand but you are only arguing 
> from the
> POV of the person introducing the shadowed global. Sure, if you never 
> have
> other people look at this code then you may be able to remember 
> precisely
> which globals are shadowed in which context (though it stands to 
> reason if
> you really can do this after a couple of years of not looking at that 
> code).
>
> However, if you talk about exchanging code with others, then you've 
> got to
> be aware that more eyeballs will look at your code - and if one of 
> those
> sees a shadowed global it is Very Unlikely that this person will 
> understand
> what this object is. Your recent message was a great example in this 
> regard
> - I am sure _you_ got exactly what you wanted but poor me, trying to
> understand what I was seeing, was utterly confused.
>
> The system should therefore prevent you from introducing those shadowed
> globals even "if you get what you want". In more cases than not I would
> presume that the shadowing is purely accidental, simply introduced 
> because
> you didn't even know that the global existed.

But I can simply load one package that by accident introduce a class 
that as the same
name as my classVariable and get in trouble. This is the idea behind 
scope I guess
so why this is a problem. because if you force the guy loading an 
unknown package to
rewrite his code then this is the worse that we can do to promote 
packages or even oo.

> So here's my question for you: Given the option, wouldn't you rather 
> use a
> variable name that does not shadow a global than using one that does?

When programming I will always avoid shadowing for reading point of 
view.
but when I load your code I do not want your stuff to mess mine.

> And if
> the answer is "yes", then what's your argument against the system 
> enforcing
> it?

Locality of changes.

>
> Cheers,
>   - Andreas
>
>
>> -----Original Message-----
>> From: squeak-dev-bounces at lists.squeakfoundation.org
>> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On
>> Behalf Of Peter van Rooijen
>> Sent: Thursday, October 16, 2003 6:14 PM
>> To: The general-purpose Squeak developers list
>> Subject: Re: [BUG]UndefinedObject(Object)>>error:
>>
>>
>>> I agree. Not bringing up the notifications during text load
>> would allow
>>> the use of ported  code, which is Peters original problem, and one I
>>> think has some merit. A fix along these lines would be
>> appreciated. Does
>>> someone care to review and test the fixes submitted so far to see
>>> whether they should do?
>>
>> Hi Daniel,
>>
>> Is it true that the interactive class creation ("accept" from
>> the browsers -
>> not "do it") always uses the ClassBuilder? If so, that would
>> seem to be a
>> good place to put checks and warnings.
>>
>> The Class>>declare: method that is used for defining the set of class
>> variables in a class, still has a proceedable check for
>> non-capitalized
>> class var names. It was in the old version and I left it in because it
>> doesn't bother me, but I have the feeling that that check
>> might be more at
>> home in the ClassBuilder (where checks such as for already defined in
>> superclass or defined more than once are already done).
>>
>> Depending on how this is envisioned, it might make sense to
>> use two Sets
>> instead of OrderedCollections in the Class>>declare: code
>> segment where kept
>> and new class var names are determined. There is no ordering in class
>> variables anyway, and they are conventionally sorted in the
>> generated class
>> definition string.
>>
>> I don't know exactly what the intended use of ClassBuilder
>> is, so I can't
>> say for sure. But in general, it would seem to be sensible to
>> have a user
>> interface that can tell you when you are doing something out of the
>> ordinary/convention/standard, and another layer that will
>> allow installing
>> all code as long as it is correct/will work, and will stop
>> everything that
>> the execution machinery won't be able to handle.
>>
>> Uncapitalized class variables would be an example: I think
>> that they would
>> probably work, looking at the way variable binding is
>> implemented, but it's
>> very unconventional for a shared variable to not be
>> capitalized. Capitalized
>> method selectors might be another example. They will work,
>> but if you use
>> them interactively, it might be nice to get notified that it's highly
>> unconventional.
>>
>> [BTW, I am not proposing such warnings, simply saying that
>> there is some
>> sense to having them. If I published a language, I would probably give
>> people a style/conventions guide, and if I did in fact do
>> style warning
>> dialogs, I would include a checkbox [x] Don't bother me about
>> conventional
>> style issues from now on! :-)]
>>
>> About using code developed on other dialects. Yes, I want this to be
>> possible, and my fix allows this already. I would like to be
>> able to _edit_
>> portable code in Squeak too. After all, a large part of
>> wanting to be able
>> to run portable programs on Squeak is to allow people who
>> prefer to (or can
>> only) use Squeak to contribute to these programs.
>>
>> So, if there is to be a warning during method editing ("The
>> code you are
>> trying to save refers to class variable BlaBlaFoo, defined in class
>> SuperBar, but there also happens to exists a global variable
>> with the name
>> BlaBlaFoo, and we just wanted you to know that that global is
>> not in scope
>> in this method. So if you were actually intending to refer to
>> the global
>> BlaBlaFoo, this code will not execute as you intended. If you
>> did intend to
>> refer to the class variable BlaBlaFoo, you can proceed to
>> save this method
>> without any worries. Have a nice day!"), I would suggest that
>> it can be
>> turned on/off.
>>
>> I would then also prefer that not warning about style issues
>> would be the
>> default, and you would have to set a preference if you do in
>> fact want these
>> warnings. It there existed a 'newbie image', I would probably
>> turn those
>> warnings on by default there.
>>
>> But, if I'm really honest, I wouldn't bother trying to get
>> these warnings
>> in. AFAIK, class vars shadowing has been in the other
>> dialects for ages and
>> I have never heard of any problems with it. I think that that
>> should not be
>> surprising, because:
>>
>> A) If you are aware that a global exists (e.g., 'String') and
>> you define it
>> as a class var, you know exactly what you are doing and you
>> get exactly what
>> you want (in other dialects as well in Squeak with my proposed fix).
>>
>> B) If you aren't aware that the global exists (e.g.,
>> 'TestClassVar'), the
>> shadowing works without you even noticing it and you get
>> exactly what you
>> want.
>>
>> Off hand, I see only two scenarios in which the shadowing
>> causes a developer
>> to need to use caution on account of class varibles shadowing globals:
>>
>> 1) One is when she subclasses a class that is not hers.
>> Because then she has
>> to check which class variables are defined in the hierarchy,
>> so she knows
>> which global names are shadowed. One doesn't subclass someone
>> else's class
>> lightly anyway, so I don't think this is a major burden.
>>
>> 2) The other is when she adds a method to a class that is not
>> hers/that she
>> doesn't know. Basically the same caveat applies, but in
>> addition she has to
>> check the variables in the pools imported by that class as
>> well. Again, it
>> doesn't seem like that would be a major burden.
>>
>> In all other scenarios, the shadowing is helpful.
>>
>> Regards,
>>
>> Peter van Rooijen
>> Amsterdam
>>
>>> Daniel
>>>
>>> Ned Konz <ned at bike-nomad.com> wrote:
>>>> On Thursday 16 October 2003 3:23 am, Nathanael Schärli wrote:
>>>>> - We change the compiler so that the principle of locality also
>> applies
>>>>> to class vars vs. globals (and not only to inst vars
>> vs. temps). This
>>>>> means that within a class and a metaclass, all
>> available class vars
>> (no
>>>>> matter whether they were defined in the class or a
>> superclass) shadow
>>>>> globals.
>>>>> - We make sure that it is not possible to define a
>> class var that
>>>>> shadows a global.
>>>>> - We make sure that the system warns about conflicts
>> between class
>> vars
>>>>> and globals whenever a change in the system (e.g.,
>> filing in a class
>> or
>>>>> creating a global) causes shadowing between a class var
>> and a global.
>>>>> - We add a mechanism to scan the system for shadowing
>> of globals or
>> inst
>>>>> vars.
>>>>>
>>>>> What do you guys think? Is there anything I am missing?
>>>>> Nathanael
>>>>
>>>> Sounds good to me, as long as the notifications happen
>> only when run
>> from the
>>>> UI.
>>>>
>>>> We need to be able to load code programmatically without
>> bothering the
>> user.
>>>>
>>>> We have a problem now with various things popping up
>> requestors and
>>>> confirmation dialogs during file-in when they really shouldn't.
>>>>
>>>>
>>>> -- 
>>>> Ned Konz
>>>> http://bike-nomad.com
>>>> GPG key ID: BEEA7EFE
>>>
>>>
>>
>>
>
>
>