Hey,

Can it be that you guys are misunderstanding each other? I think that
Stef is okay with a system that does not allow creating class vars that
shadow globals. However, there are cases where these things can just
occur without interactively creating them (e.g., when loading a
package), and even if the system warns you (as it now does in case of
shadowed instance variables), there will be a short period of time where
the conflict between the class variable and the global is there.

And it is exactly during this time, where the current semantics of
Squeak (with globals shadowing class variables within subclasses) is
confusing and can break the system. (See my previous post for a detailed
explanation).

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?

Nathanael


> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Andreas Raab
> Sent: Donnerstag, 16. Oktober 2003 19:00
> To: 'The general-purpose Squeak developers list'
> Subject: RE: [BUG]UndefinedObject(Object)>>error:
> 
> 
> > 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
> > >
> > >
> > 
> > 
> 
>