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