Some notes on Elvis and Other Null-Safe Operators

[Reinier Zwitserloot]

There's a big difference between:

'available in some third party library'

and

'available in java core libraries'.


Take Pair (also known as Tuple). There are a couple thousand  
implementations floating around, I bet. Everyone rolls their own,  
because including a complete library just for Pair/Tuple, especially  
considering that in java land, adding a library is not a matter of  
tossing a one-liner in your java file and letting java/javac take care  
of the rest (we need ant, maven, ivy, protoJ, or other tools to go  
hunt down those dependencies for us).

It's just too small - the effort of adding any form of dependency  
management is much bigger than rolling your own half-baked Tuple.java.  
That's an entire class, so imagine what happens for the elvis  
operation. The effort of even adding the dependency if there's already  
a dependency framework in place is borderline too much effort for  
something as simple as the elvis operation.

This same process happens on the small scale as well: Because writing  
1 if statement is so simple, nobody initially bothers to roll their  
own elvis utility method. In theory, after needing it a couple of  
times, you should abstract away the elvis operation, but its such a  
trivial operation that the lines blur and there's no urgent impression  
upon the programmer that something is amiss in the source base and  
needs abstracting.



So, is the elvis operator a good idea? Probably - I'm mostly  
agnostic*, but if I had to make the final call, sure, why not.  
However, we clearly cannot say that 'the library path doesn't work' -  
because we haven't tested the library path yet. Toss it into  
java.lang.Something, and if people then still won't go for it, THEN we  
know it won't fly as a library**.


*) The biggest problem with the entire elvis line of thinking is that  
it promotes nulls and null handling at runtime, which I think is  
fundamentally un-java-like. I've heard plenty of complaints that it  
would be too complicated, but I strongly prefer moving nullity into  
the type system. Not the Fan copout - that doesn't work; you'd still  
have plenty of situations where you have a variable, it should have  
been compile-time possible to determine its nullity, but you don't  
know and the compiler/editor can't tell you (because of generics). I  
want the complete solution, which includes 4 nullity states:  
Definitely not legal to hold null, Absolutely legal to hold null,  
Might or might not legally hold null, and legacy type (analogous to  
the raw type for generics, and with similar semantics: Acts like might  
or might not legally hold null in practice, but you can assign it to  
any of the other nullity states, and get a warning instead of an  
error). It's not that complicated - certainly simpler than generics,  
and mostly the same principle.

**) But how would the elvis operation in a library look like? Without  
closures or some other control statement abstraction, any elvis  
operation as a java static method that I can think of is considerably  
more horrible. Adding CICE to java would help, but not much.

  --Reinier Zwitserloot



On May 18, 2009, at 13:37, Stephen Colebourne wrote:

> 2009/5/18 Schulz, Stefan <schulz at e-spirit.de>:
>> Joseph D. Darcy wrote:
>>> A belated reply, in general and for null handling in particular,
>>> addressing the problem with libraries is preferable to addressing  
>>> the
>>> problem with a language change.
>>
>> Just as a side note: while such a library based solution for elvis  
>> is formally possible, without some closure like construct, the  
>> advantage of evaluating the RHS expression on demand only will be  
>> lost.
>
> I'd also note that libraries have been available for elvis for some
> time, yet they are not especially widely used. All the evidence is
> that developers would rather code the if statement themselves than
> import a library.
>
> Stephen
>