valhalla-dev Digest, Vol 7, Issue 24

[Peter Levart]

On 01/08/2015 12:33 AM, Vitaly Davidovich wrote:
>> For value-types:
>>      x eq y  -->   (x == y)
>
> You mean for primitives? Custom value types won't work with == as there's
> no operator overloading.
>
> Getting back to the null aspect though, here's my take ...
>
> I think we should not introduce a new operator such as eq when we already
> have a "universal" equals.  What you really want to say is something like
> this:
>
> <any T> void foo(T t) {
>      if (T.default.equals(t))
>          System.out.println("got default/null");
>      else
>          System.out.println("got non-default/null");
> }
>
> Now, the obvious problem here is that this NPEs on reference types since
> T.default yields a null and you can't reverse the comparison because t may
> be null.  So, what you'd like here is similar to what .NET does.  Introduce
> an IEqualityComparer<T>-like JDK interface, and provide a way to obtain a
> "default" comparer for a given type.  In .NET, there's a generic class
> called EqualityComparer, which has a static property called Default (e.g.
> EqualityComparer<T>.Default).  That internally (in static constructor)
> figures out, based on inspecting T's capabilities and type, which is the
> default equality comparer and then hands out that sole instance on each
> Default access.  Ultimately, what you want here is instead of doing
> T.default.equals(t), you want some other class to define an "<any T>
> boolean equals(T x, T y)" which can internally handle one side being null
> (for ref types).

This sounds similar to the following:

http://cr.openjdk.java.net/~plevart/misc/valhala-hacks/util/AnyHelper.java

This can be used as a temporary work-around for lack of such features in 
current prototype.

Peter

>
> tldr; well behaved classes already should be handling null inputs in their
> equals() impl, so we should find a way to reuse that instead of introducing
> a new operator/keyword.
>
>
> On Wed, Jan 7, 2015 at 6:07 PM, Thomas W <twhitmore.nz at gmail.com> wrote:
>
>> Hi Simon, Vitaly, people,
>>
>> Lots of people have been talking about adapting Collections for 'any'
>> type. Going forwards, I do not believe we should be writing code that
>> explicitly uses/ or checks for nulls (though we may be backwards-compatible
>> for a while) any more than we should be writing or calling a Duck.woof()
>> method.
>>
>> To answering a few questions:
>>
>>> a) What are the actual semantics?
>> For ref-types:
>>      x eq y  -->   (x != null && x.equals(y))
>> For value-types:
>>      x eq y  -->   (x == y)
>>
>>> b) How is this different to the approaches already outlines earlier?
>> It provides a basic logical building-block (equality check) at the
>> language level, in a way that works both for primitives/valuetypes and for
>> nullable references. It addresses a very big long-standing pain point in
>> Java application development. It avoids writing/ or encouraging
>> "Duck.woof()" style-hacks -- null checks -- into a domain that does not
>> uniformly support them.
>>
>>> Why do we need a new special operator? What's wrong with using equals
>> () and having the specializer rewrite that for primitives?
>>> What's wrong with using equals() and having the specializer rewrite
>> that for primitives? For other types
>>> (refs and custom value types), it should just delegate to the real
>> equals.
>>
>> To have a proper logical equals in one operator, which is independent of
>> implementation & null-safe for reftypes.
>>
>> What's wrong is writing null-checks & nulls, in a domain where nulls may
>> not exist.
>> We are not dealing with Dog, we are dealing with Animal and there should
>> be no 'woof()' method.
>>
>>> What's wrong with using equals() and having the specializer rewrite
>> that for primitives? For other types
>>> (refs and custom value types), it should just delegate to the real
>> equals.
>>
>> What's wrong with an operator that logically has exactly the right
>> meaning, without exposing details that don't exist in the domain?
>> It also provides a vast benefit for application programmers, as this kind
>> of requirement is ridiculously common in hundreds of millions of lines of
>> application code.
>>
>>
>> Regards,
>> Thomas Whitmore
>>