I am wondering: In what case does what you are using/suggesting differ
significantly from simply catching a NPE that a specific code block throws and
letting said block evaluate to null in that case:
def eval(bool nullSafeQ, Closure cls) { try { return cls() }
catch(NullPointerException e) { if(nullSafeQ) { return null }
throw e }}
(It feels a bit like what you wants is tri-logic/SQL type NULL support in
Groovy, not treating Java/Groovy null differently...)
Cheers,mg
-------- Ursprüngliche Nachricht --------Von: "ocs@ocs" <o...@ocs.cz> Datum:
14.08.18 17:46 (GMT+00:00) An: dev@groovy.apache.org Betreff: Re: suggestion:
ImplicitSafeNavigation annotation
Jochen,
On 14 Aug 2018, at 6:25 PM, Jochen Theodorou <blackd...@gmx.org> wrote:Am
14.08.2018 um 15:23 schrieb ocs@ocs:
H2,
However, “a+b” should work as one would expect
Absolutely. Me, I very definitely expect that if a happens to be null, the
result is null too. (With b null it depends on the details of a.plus
implementation.)
the counter example is null plus String though
Not for me. In my world, if I am adding a string to a non-existent object, I
very much do expect the result is still a non-existent object. Precisely the
same as if I has been trying to turn it to lowercase or to count its character
or anything.
Whilst I definitely do not suggest forcing this POV to others, to me, it seems
perfectly reasonable and 100 per cent intuitive.
Besides, it actually (and expectably) does work so, if I use the method-syntax
to be able to use safe navigation:
===254 /tmp> <q.groovy String s=nullprintln "Should be null:
${s?.plus('foo')}"255 /tmp> /usr/local/groovy-2.4.15/bin/groovy qWARNING: An
illegal reflective access operation has occurred... ...Should be null: null256
/tmp> ===
which is perfectly right. Similarly, a hypothetical “null?+'foo'” or
“@ImplicitSafeNavigation ... null+foo” should return null as well, to keep
consistent.
(Incidentally, do you — or anyone else — happen to know how to get rid of those
pesky warnings?)
Thanks and all the best,OC
