Some notes on Elvis and Other Null-Safe Operators
reinier at zwitserloot.com
Mon May 18 21:13:35 PDT 2009
There's a big difference between:
'available in some third party library'
'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
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.
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
>>> 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
> 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.
More information about the coin-dev