Color.Equals seems totally useless

  • Thread starter Thread starter Ben Voigt [C++ MVP]
  • Start date Start date
Peter said:
Likewise, in Jon's reply to your "1+1=3" example, you are allowing your
prejudice of what that exact sequence of characters means in the real
world to affect your interpretation of what's going on in the computer.
While it's helpful for the compiler to be designed so that adding 1 to
itself results in 2, just as it does in the real world, some insane
compiler designer could in fact declare that his compiler will result in
3 when that operation is performed.

He could do so for any variety of reasons, including that one or more of
those symbols don't actually mean in his compiler what they mean in the
real world, or simply that he wants to be arbitrary. But regardless, if
he writes the specification for the compiler stipulating that that's
what's supposed to happen, then if the compiler does exactly that, then
the compiler is bug-free (at least with respect to that feature).

You may rightfully say that the actual design of the compiler is flawed
(or even "buggy"). But the software itself is operating exactly as it
was designed, and thus is NOT flawed or buggy. It's not a bug for that
compiler, with that design, to make 3 the result of adding 1 and 1 (or
whatever operation might actually be represented by the sequence of
characters "1+1").
Click to expand...

A better example might be a system that produces "1 + 1 == 10". There is
clearly a domain of interpretation for which that is not "buggy" even in
design, though there could also be people who think that it is buggy, due to
preconceived notions of what "1 + 1" or "10" /should/ mean.
 
Jon,

I call something a bug when it does the 'wrong' thing. So when some code
does the 'wrong' thing, I don't care whether the 'wrong' thing was
introduced in the design, specification, or development of the code. Let's
say that Msft defined "List.Add" as removing an element from the list and
"List.Remove" as adding that element to the list. Is that a bug? Yes, of
course it is (IMHO). Is it coded correctly? Yes, but it is still a bug in
a broader sense. That is my point (which I stated this earlier). Equal
means "equal:, not equal if we name some stuff internally, but that might
all change and it is inconsistent and not well documented "equal". Before
Peter jumps up and down; Peter, please find me the clear concise Msft
definition of Color.Equal.

IMHO, Color.Equal is so broken that it is almost as bad as calling a class
SortedList when it is not a list and does not even implement IList, but
that's a whole 'nother topic. :)

And just to be clear, I love C#, am grateful every day to Microsoft for
creating .NET (especially on devices), so I'm not bashing C# or Msft, I'm
just calling it like I see it.

So, going back to the OP, is Color.Equal useless? If so, then it kinda
proves my point - no?

Hilton
 
Hilton said:
I call something a bug when it does the 'wrong' thing. So when some code
does the 'wrong' thing, I don't care whether the 'wrong' thing was
introduced in the design, specification, or development of the code.
Click to expand...

Then you're using the term inconsistently with the rest of the
industry. For instance, from http://en.wikipedia.org/wiki/Computer_bug

<quote>
A software bug (or just "bug") is an error, flaw, mistake, failure, or
fault in a computer program that prevents it from behaving as intended
(e.g., producing an incorrect result).
</quote>

By that definition, if the software is working *as intended* it does
not have a bug.

Then from the jargon file:
http://intranet.cs.man.ac.uk/software/jargon/html/B/bug.html

<quote>
An unwanted and unintended property of a program or piece of hardware,
esp. one that causes it to malfunction.
</quote>

The effect of Color.Equals is the intended one, therefore it doesn't
fall under this definition either.
Let's
say that Msft defined "List.Add" as removing an element from the list and
"List.Remove" as adding that element to the list. Is that a bug? Yes, of
course it is (IMHO).
Click to expand...

It's poor design. It's not an implementation bug.
Is it coded correctly? Yes, but it is still a bug in
a broader sense. That is my point (which I stated this earlier). Equal
means "equal:, not equal if we name some stuff internally, but that might
all change and it is inconsistent and not well documented "equal". Before
Peter jumps up and down; Peter, please find me the clear concise Msft
definition of Color.Equal.

IMHO, Color.Equal is so broken that it is almost as bad as calling a class
SortedList when it is not a list and does not even implement IList, but
that's a whole 'nother topic. :)
Click to expand...

I agree that without hearing any reasons why it should be designed that
way, it certainly looks like it would make more sense to design it a
different way. That's not the same thing as it being a bug in the
commonly accepted use of the term.
And just to be clear, I love C#, am grateful every day to Microsoft for
creating .NET (especially on devices), so I'm not bashing C# or Msft, I'm
just calling it like I see it.
Click to expand...

To be clear, your complaints have nothing to do with C# itself. The
..NET framework library isn't the same as C# the language.
So, going back to the OP, is Color.Equal useless? If so, then it kinda
proves my point - no?
Click to expand...

It's not useless if you want to know whether two Color instances are
the same including whether or not they're named.
 
Hilton said:
a broader sense. That is my point (which I stated this earlier). Equal
means "equal:, not equal if we name some stuff internally, but that might
all change and it is inconsistent and not well documented "equal".
Click to expand...

Equal can mean all sorts of things. If you compare 2 lists then they will
always return not equal because they are not the same instance, even if the
lists contain the same elements. In the case of the colour structure we have
2 classes which are probably internally something like this

Color1:
int Colour = 0
int NamedColour = 0

Color2:
int Colour = 0
int NamedColour = 100

Remember this is just a wrapper that *represents* a colour. The designers
would have had 3 choices with equals 1) compare instances 2) Compare just
the Colour field 3) Compare the Colour and NamedColour fields. They simply
chose number 3. To me picking option 2 would be a design flaw because the 2
structures are very clearly not equal.

Michael
 
Back
Top