[BUG]Collection>>removeAll:
Andrew C. Greenberg
werdna at mucow.com
Thu Aug 29 14:29:15 UTC 2002
On Thursday, August 29, 2002, at 02:10 AM, Richard A. O'Keefe wrote:
> Allen Wirfs-Brock <Allen_Wirfs-Brock at Instantiations.com> wrote:
> I must have missed the messages where you quoted the standard,
> but I did consult the actual text of the actual standard (not a
> draft). The words are what they are and I see how you could
> interpret them such that they allow the position you are taking.
>
> GOOD. Thank you very much.
>
> However, as a very active participant in the drafting of the
> standard, I can tell you that it was not the committee's intent
> to require this!
>
> At least in this country, when they interpret a law, judges are
> required
> to interpret the text of the law itself, in the light of other laws and
> how courts have interpreted them and the law in question. But they are
> NOT allowed to consider Parliament's intent.
Now it's my turn to say, Oh Come On. Richard, having abandoned
technical argument, has turned to legal advocacy instead. While I
welcome a parry or two on my home turf, I think there is really no
place in this forum for such sophistry.
For perspective, Richard, the opposite is true in the United States --
although it is a question of judicial philosophy. I am no expert on
the subject, however, but I am aware of several recent UK opinions
involving technology law where judges did precisely what you state they
are not permitted to do to resolve ambiguities in the law, expressly
distinguishing between Common Law jurisdictions, such as the UK, (most
of the) US and Canada, and civil law jurisdictions.
In general, where a law does not clearly state how an issue is to be
resolved, or states in different places conflicting suggestions, it is
quite common to use (among a huge litany of other devices) legislative
history manifesting original intent to determine what is the law.
> The same is generally held to apply to programming language standards,
> at least that's how it has been done in the case of C and Ada.
Huh? Where is this written? Is this simply the rule you are adopting
because any other puts your conclusion in jeopardy? Indeed, I don't
believe it is true: the original Ada standard was so full of holes
there could be no conforming implementation. Ultimately, the standard
and implementations moved until it was possible to certify one or two.
> Indeed,
> there is a very clear clash between the C89 standard and the express
> intent of the people who wrote it, and the text of the standard was
> held
> to be definitive, NOT the authors' intent.
"held to be definitive" By which court of chancery? Come on, Richard.
As between you and Alan,
> The reason for this is obvious. People trying to implement what the
> standard says, and people trying to use the standard as reference
> material to determine what they can expect, have in the past been
> most unlikely to have access to the authors or any other way of
> determining
> their intent other than the text itself.
1) Who is trying to implement the ANSI standard?
2) I thought you were arguing what the standard SHOULD be, not what it
was. Where Alan Wirfs-Brock informs us that the standard, to the
extent you are relying upon it, would be likely to be revised even to
the extent you stretch the words to support your position, isn't that a
powerful argument that your position is, well, at least, tenuous or
hyper-legalistic?
> Nor can we always appeal to prior art.
Why not? Is it, perhaps, because such argument might not support your
conclusion?
> Sometimes a standard extends
> the coverage of things. That's the case in ANSI C, for example.
> Before the ANSI standard, malloc(0) was undefined and so was
> free(NULL).
> In many systems, they didn't work. The ANSI C standard said they had
> to.
>
> The prior art for #removeAll: may well have been broken; although you
> will search textbooks and reference manuals in vain for any hint of
> this.
To the contrary, the existing "prior art" may have been correct, and
the existing textbooks and reference manuals, which describe the
principle of the non-mutating iterand, hint dramatically to the
contrary of Richard's position. Perhaps he is marginalizing twenty
years of wisdom, not only because he believes it is mistaken, but
rather because it does not support his desired result?
> Someone with access to the ANSI Smalltalk standard discovering this
> could
> reasonably conclude that it was the intent of the ANSI committee that
> the
> bug be fixed.
Yeah, that well-published ANSI Smalltalk standard is just so well-known
and commonly relied upon by newbies and experts alike. Be real. If
this is your strongest argument, the battle is lost.
> Indeed, the _only_ thing about #removeAll: that makes the
> "fixed" interpretation implausible is returning the argument instead of
> the receiver, and someone noting that the return value is unspecified
> in
> ANSI Smalltalk could again reasonably conclude that this removed the
> only barrier to an exceptionless reading.
Duh. That is to some of us a powerful argument why it can't mean what
Richard says it means.
> This is an issue we missed.
>
> And #addAll:, and whether #hash may be applied to cyclic objects, and
> ...
It would appear that Richard relies heavily on the standard to support
the points he loves, and disses it otherwise. Of course the standard
is flawed. It is, after all, the first draft, and recently adopted.
The "authoritative" view will be time-tested, and we shouldn't resolve
the interstices and obvious omissions by legalistic mumbo-jumbo. Take
it from me as a seasoned lawyer -- such argument rarely leads to
justice.
> This is another reason why we have to work with the text,
> rather than with the intent of the committee.
Nobody has to work with the text. This is the difference between a
promulgated standard and the law.
At the end of the day, the question is this -- what should Squeak do?
Richard argument from the text of the standard is only arguable, and to
the extent arguable, Alan's explanation only further reinforces the
extent to which Richard is mistaken about what the rule should be. At
any rate, I see no need to "jump on the standards bandwagon" as the
sole basis for proceeding, in view of the obvious controversy.
We should either do nothing, or catch the error. Nothing more.
More information about the Squeak-dev
mailing list
|