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

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? And if
the answer is "yes", then what's your argument against the system enforcing
it?

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