Hacker News Reader

Comment by cousin_it | Hacker News Reader

I think the problem is that == compares pointers, when it should've been sugar for .equals() instead.

it's tough. If a language has pointers, then you would expect == to compare whether the two sides have the same value (an address). I don't see a way around that.

How would you expect a programmer to ask "do these two pointers hold the same address?" .holdsSameAddressAs()?

D and Python use the "is" operator to compare reference identity. It is the lesser used operator and the more advanced concept, so using == for reference comparison is just a newbie trap, doubly so since you have to use == to compare equality for primitives.

But it's not true. Mary is a sign-holder. She's holding a sign that says "32 Crestview Road". John is also a sign-holder. Today his sign also says "32 Crestview Road".

Question: is Mary John?

You want the answer to be "yes" (Mary is John) since the is operator asks whether they hold addresses which have the same value.

But of course it's a broken terminology, because Mary and John are two different people, with their own physical locations etc. So you're overloading a word "is". I get that it works, but so does anything else you make programmers learn.

I think Haskell gets it right. All values are immutable. Calling == for two values of some type invokes the Eq implementation for that type, e.g. for strings it's string equality. For the type "IORef a" (box that can contain different a's at different points in time) it compares the identity of the box, not the contents. In fact it can't compare contents, because the type of == stops it from using impure operations like accessing current contents.

The same approach could work in imperative or OO languages. For immutable types == should be value equality, while mutable types are analogous to IORef or IOArray, so == should be reference equality. It comes down to observational equality, different instances of the number 2 shouldn't be distinguishable, but different mutable containers with the same contents should be distinguishable because you can make their contents different. I think observational equality is a good fit for pretty much all uses of equality in programming.

But in the ideal situation it would be

    assertTrue(mary.getSign == john.getSign)
    assertFalse(mary.getSign is john.getSign)
    assertFalse(mary == john)
    assertFalse(mary is john)

right, you and I are agreed and your third sentence is exactly what I was arguing for - it goes against the OP's request that that third sentence evaluate to true.

this was the OP in this thread:

https://news.ycombinator.com/item?id=14348066

> How would you expect a programmer to ask "do these two pointers hold the same address?"

In Java and C#, you rarely need to ask this question.

In fact, the .NET Framework overloads String, DateTime[0], etc so you can use == for almost all comparisons.

[0]: http://stackoverflow.com/a/1205462/266535

Except java doesn't have pointers, it has references. You can't do pointer arithmetic on references, nor can you take addresses and dereference.

I'd expect a programmer to ask: "is this object the same as this other object" and have the language support that by an operator like `is`. Instead of overloading `==` to mean value and reference equality depending on the context.

java references are pointers; the fact that you can't do math on them is immaterial. In java, pointers and primitive types are first class (can be assigned, compared, passed and returned from functions, be members of other objects) while the object themselves are not (they only live in the heap and can't be aggregated).

I think the distinction between "this value is a reference that can be derefenced to get another value that is stored somewhere else" and "this value is an address into some contiguous storage where another value may be stored" is a useful one. Personally I like "reference" and "pointer" to make that distinction, where a pointer is a specific implementation of a reference.

However, that terminology is by no means universal. While, from what I can tell, "reference" as defined above is favoured in the Java and C# community, "pointer" is still used plenty. For example, the Java spec says "The reference values (often just references) are pointers to these objects"

All that being said, I do agree with what I think is the spirit of your comment, which is that when your language doesn't allow pointer manipulation it is less useful to ask whether two values point to/reference the same value.

> How would you expect a programmer to ask "do these two pointers hold the same address?" .holdsSameAddressAs()?

In C++, yes, you do

    (&a == &b)

and the plain == is used for the common case of actually doing what you mean (what in Java would be .equals()).

Actually, that's not always correct in C++ (it is in C). It is possible that either type has the operator& overloaded, so instead the proper way to do it is:

    (std::addressof(a) == std::addressof(b))

http://en.cppreference.com/w/cpp/memory/addressof

Thanks (I didn't even know this operator was overloadable)!

==& ?

I use .equals far more than ==.

Reply on news.ycombinator.com