[Mono-devel-list] GetHashCode () differences from Microsoft

[Paolo Molaro]

On 06/04/03 Ben Maurer wrote:
> > You can certainly make those kind of changes to your local cvs tree,
> > but those changes should not be committed. The right thing to do is
> > to fix the tests to not depend on a particular GetHashCode()
> > implementation. 
> Is there any disadvantage to committing them? Would it do any harm?

Yes. We don't want to add workarounds for broken tests.

> The reason I would like to get this stuff "fixed" is because I think
> that the Rotor tests can give us some very valuable data. It is a very
> through test suite, and is a great test of our progress. However, if we
> start to modify the code, it becomes less valuable. No longer will it be
> possible to see that mono is working correctly by running the external
> test suite.

Which part of "those are broken tests" do you don't understand?
Say, suppose at some point rotor and the commercial MS framework
use two different hashcode implementations for string (I assume now they
are the same) and then a test suite is published for rotor and one for
the commercial framework. Are you going to commit to cvs different
versions of GetHashCode each time you run the test suites? That's
stupid.
The right thing to do is to add to our own test suite the tests to make
it more complete. Looking at the rotor test suite is only useful to see
what kinds of tests we may be missing. The tests you see there need to
be scrutinized and checked for correctness: don't assume that they are
correct if rotor passes them!

> I also think that the tests could provide some great marketing power.
> When we get 100% of the tests to pass, I am sure it will be newsworthy.
> However, 100% (with tests modified where we think Microsoft is wrong) is
> not quite as spiffy.

Yeah, imagine the comments, we run 100% of the tests, even the ones that
are broken! That's very nice advertising.
Since they didn't release the test suite with a license that all of us can use,
I much prefer being able to say we pass 100% of our test suite than
being able to say we passed some random test suite after making
nonsensical changes to our sources.

> Because Rotor is designed as an ECMA compliant implementation of the

Dude, in the real world, design != implementation != documentation.
Even if something is designed to match a spec, that doesn't mean that it
does. This is Reality check 101.
Plus, the standard doesn't define how GetHashCode is implemented.

> Of course I am not a lawyer, and of course that means you should not
> trust me! However, I have some good sources

... and you're interpreting them in a way that may not be correct, such
as assuming that the one that reads the sources and takes pseudocode
notes can be the one that writes the code for mono.
We want to stay on the safe side and we don't care if others take
another path.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better