valhalla-dev Digest, Vol 7, Issue 24

[Vitaly Davidovich]

Why do you need language feature for #2? What's wrong with calling a lib
method that wraps this up for you? Changing the language is a high barrier
to entry and personally,  it seems like eq is just shorthand for a generic
method that can deal with this just as well.

Now, one language change I'd appreciate is the elvis operator since you
can't emulate that via lib.  But, let me stop here as we're going off on a
tangent.  Broadly speaking, I don't think value type and specialization
work should also be used to tackle any perceived issues with null.

Sent from my phone
On Jan 7, 2015 8:17 PM, "Thomas W" <twhitmore.nz at gmail.com> wrote:

> Hi Vitaly, people,
>
> > So i thought having equality externalized means you don't deal with it
> in the generic class - you call a black box passing a default and target
> item, and get an answer.
>
> That's fine as a possible *implementation mechanism*, but it doesn't help
> the language syntax. Nor does it expose so much to the Hotspot optimizer.
> It's a reasonable idea and I'm happy to consider it, though :)
>
> > Now yes the default for ref types is null but for better or worse null
> isn't going away in java so pretending it doesn't exist is just silly.
>
> Null absolutely exists in reftypes, but it absolutely does not for
> primitives or value-types. We should be recognizing the /logical meaning/
> of eg Collections code that writes 'null', and provide a meaningful
> expression that applies across both reftypes and value-types.
>
> I did previously note that nulls are a huge pain-point for application
> developers in Java. So it seems very unlikely that I am pretending they
> don't exist! I want to address null at a language level for the Equals
> operator, so that we have a "universal equals" that works at a logical
> level -- across nullable/ and valuetypes equally. This would be hugely
> beneficial to application development, in a way that IEquatable/
> IEqualityComparer would not.
>
> A quick outline of what 'null' is typically used for in Collections-type
> code may help illustrate my point:
>
> 1)   elements[i] = null;
>        // clearing or defaulting;  -->  T.empty aka T.default.
>
> 2)   if (cand != null && cand.equals(item))
>        // 'eq' operator;    -->  cand eq item
>
> 3)   if (node == null) return null;
>        // not found returning sentinel;  -->   if (node == null) return
> T.sentinel
>        // of course, we should suggest to use getOrDefault() or
> getOptional() if a sentinel is unsuitable -- for either reftypes or
> value-types!
>
> I can be quite clear, this very fairly recognizes & supports 'null' in
> reftypes. But very importantly, it avoids requiring or encouraging 'null'
> to be written in such code -- by providing meaningful alternatives, which
> are meaningful for primitives/ valuetypes as well as for reftypes.
>
> Animal.speak(),  rather than Duck.woof().
>
> Regards,
> Thomas
>