Re: First class developer: who ?

Arne Vajhøj wrote:
On 12-03-2010 21:08, Arved Sandstrom wrote:
Arne Vajhøj wrote:
On 12-03-2010 05:26, Arved Sandstrom wrote:
Both terms actually have clear English meanings - "equality" means (or
should mean) that two things *are* the same, and "equivalence" means (or
should mean) that two things can be substituted, that they behave the
same way.

A mathematical and CS definition in fact tracks the common English
meanings of these 2 words, and the language concerning Object.equals
that Patricia quoted does say exactly this: equals is an implementation
of equivalence.

My point is that the common English, the mathematical and the CS
definitions of the two terms are pretty much the same. And programming
languages that differentiate between the two also track those
definitions. We see that Java does.

I don't think Java follow those rules.

I assume that you consider equals to be equivalence and
== to be equality.

But it is not so.


public class ZZ {
public static void main(String[] args) {
int iv = 2;
double xv = 2.0;
System.out.println(iv == xv);

I do consider == to be equality (identity). Same object for references,
same value for primitives...that's equality.

But 2 and 2.0 are not identity equals.

No, but as I indicate I don't see that we ever compared 2 and 2.0 for identity in your example. You can't do that with direct use of ==, because of promotion.

This is one of the C-based hiccups of Java. For primitives of different types we shouldn't even be asking the question ==?

An implementation of equals() I consider to be _an_ implementation of an
equivalence relation; == is clearly another.

I'm not that perturbed by your example. Java == equality for primitives
of different types is what we define it to be, so defining it to be an
operation that takes place after primitive conversions is not wrong. In
effect we're not saying that (int 2) == (double 2.0), we're saying that
(double 2.0) == (double 2.0); the binary numeric promotion happened
before the ==.

That promotion is done by ==.

"Done by?" I don't see that. "Done on behalf of", sure. Unless a bytecode guru tells me otherwise I expect that == just like + is blissfully unaware that it could ever be asked to work with two primitives of differing types.

Now, if each binary operator duplicates all the numeric promotion logic I could see that they are responsible for it.