From: "Doug Way" <dway at riskmetrics.com>
> On Tuesday, October 7, 2003, at 09:07 PM, Peter van Rooijen wrote:
> > Would incorrect variable binding be such a more serious problem? The
> > shared
> > variable binding/lookup logic is broken (seems it has been for 7 years
> > or
> > so) and I corrected it for 3.5 last week. Yesterday I saw that in 3.6
> > the
> > mechanism has been overhauled, but sure enough the error is still
> > there. If
> > you think this might be serious enough to warrant a new build, let me
> > know
> > and I'll make it a priority to get you a change set that fixes this
> > for the
> > 3.6 mechanism.
>
> Well, only a "major" bugfix would warrant changing 3.6 now, since the
> 3.6 release is now done.  Any bug which has been around for more than a
> year or so can not really be considered a major bug, so no, we won't be
> slipping that fix in now...

Doug,

I'm not sure how to respond. but I'm going to try:

**On the one hand:

If a bug is to be deemed non-major simply because it has been around for
years, then I would agree that this bug is probably indeed not a major bug.

I can't see the logic of the premise, however. I could see that something
would be deemed not a major *problem* if it has been around for years
without anyone noticing it, or at least, reporting/fixing it.

This could make sense even if, *as a bug*, it is major.

It does seem to be a rather inward-looking viewpoint.

I mean inward-looking in the sense of: "if none of the historical Squeak
users noticed this (or was bothered enough to take any action) for so long,
it can't be very serious". In other words, the norm for "quality that
matters" is what the historical user base has been able to live with for
more than a year.

One might reasonably argue that this is a stretch, but then it is only a
small stretch, which I believe makes a valuable point. How inward-looking is
the Squeak community? How much does that hurt?

I freelu gtant taht I don't know the answers to those questions.

**On the other hand:

The scope rules of shared variables are described in the blue book. It
doesn't explicitly describe the resolution process, but AFAICT it doesn't
take more than a few minutes to figure out what the effect of the resolution
process is supposed to be.

I have worked with various Smalltalk dialects over the course of many years,
and I haven't noticed any deviation of the blue book shared variable scope
rules in any of those.

To my mind, what the meaning of variable names appearing in the code is, is
rather essential for a programming language. If an implementation deviates
from the norm in that respect, I would have no problem labeling that as a
serious bug.

**What this comes from:

I came upon this issue in Squeak when I tried to install a program that runs
unmodified in VisualWorks, VisualAge and Smalltalk/X, and I could not even
load it into an unmodified Squeak image.

What happens is that there is a check in the class definition installation
code that throws an error when a class variable is defined that has the same
name of an existing global variable. However, a class variable having the
same name of an existing global is totally OK. If not, the validity of each
and every program that uses a class variable would depend on what globals
happen to be present in a particular image. I doubt anyone would argue that
that is how it is supposed to be.

So, I comment out the check to let the code be installed. Installation
proceeds without any further complaints.

I run the tests of the installed program. Now there is another problem.

Upon inspection it turns out to be this: while the class variables with the
same name as a global are correctly processed in the class defining them, in
subclasses the same name is taken to refer to the global. Another way of
saying this is that class variables with the same name of a global are not
inherited.

It doesn't take much time to see the source of the problem, which is
incorrect name resolution logic during the method compilation process. I
would certainly call this a major bug, but I've already said all I want to
say about that now ;-).

> However, we should certainly consider the fix for 3.7alpha.  Have you
> already submitted a [FIX]?

Like I said, I have not. But I would be happy to *if* we agree that this
wants fixing.

I have no desire to write the fix, test it, find out how to submit it (is it
okay to send a message to this list with a zipped changeset attached?),
submit it, to be then told that this is a fundamental change for what is not
a serious problem (because no one complained about it in years), and it
might break something (although it should not, it might), so it won't get
in.

After all, a major part of my wanting this corrected is to be able to run my
programs in an undoctored Squeak image. If that is not in the cards, I might
as well make the changes without submitting them as a fix, or simply not
bother about my programs running on Squeak.

BTW, there is a funny twist to this. I believe the license requires one to
share changes made to certain parts of the system. I don't know exactly
which parts of the system qualify, but I would not be surprised if the parts
affected here do infact qualify. Then after that, I don't know what action
constitutes sharing the fix :-).

So, I would appreciate some guidance in this respect.

Best regards,

Peter van Rooijen
Amsterdam

> - Doug