groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ocs@ocs" <>
Subject Re: suggestion: ImplicitSafeNavigation annotation
Date Tue, 14 Aug 2018 12:25:08 GMT

> On 14 Aug 2018, at 1:38 PM, wrote:
> IMHO, there is an ever so subtle difference between navigation - using the . operator
explictly or implicitly (as with indexing) - and arithmetic.

do please correct me if I am wrong, but I understand in Groovy, arithmetic should be just
a convenience thin syntactic sugar over messages; e.g., “a+b” should be full equivalent
to “”, but for the syntactic inconvenience:

To me it seems rather unlucky and inconsistent that although I can write “a?.plus(b)”,
I can't do precisely the same with its more convenient “a+b” equivalent. With other operators
it is even more important, e.g., “a<<b”, which, in my experience, is used much more
often as a shorthand for something like “a.append(b)” with generic objects a and b than
as a numeric shift.

> I am personally perfectly happy for my arithmetic expressions to fail with any applicable
exception if I throw unacceptable values at them.

As for the (in)convenience of NPE vs null-propagation (or, in other words, (un)acceptability
of nulls inside expressions), I guess it would rather be in the eye of the beholder.

Do please note though I am not suggesting to remove the possibility to rely on NPE which you
cherish, nor I am suggesting even changing the default behaviour in the slightest; what I
would like to see in Groovy would be a way to intentionally switch to the non-NPE null-propagating
behaviour where needed by very explicit using of an appropriate annotation. You, of course,
would never be forced to use the thing :)

Thanks and all the best,

> Den 2018-08-14 13:28, skrev ocs@ocs:
>> Gentlemen,
>> some NPE-related problems of today brought me to re-interate one of my
>> older suggestions.
>> We have the so-called “safe navigation”[*], which in some cases allows
>> a null to be propagated out of an expression instead of throwing a
>> NPE. At the moment, it can be triggered for a particular
>> sub-expression (like property/method-call and, as of 3, newly also
>> indexing) using a question mark (e.g., “foo?.bar()” or “foo?[bar]”).
>> Do please correct me if I am wrong, but far as I know, there still are
>> expressions which do not allow the “safe mode”, e.g., arithmetic
>> (“a+b” etc). Furthermore, there are cases when one simply wants a
>> bigger block of code to contain only null-propagating expressions and
>> never NPE; in such case, using the question mark syntax is both
>> inconvenient and error-prone (for it is very easy to forget one of the
>> lot of question marks needed in such a code, and then get an uncaught
>> unwanted NPE).
>> For these reasons, I would suggest adding a new annotation, whose name
>> might be e.g., “ImplicitSafeNavigation”; it would simply force a
>> null-propagation to be implicitly and automatically used for *all*
>> expressions in the annotated scope, i.e., NPE would never be thrown
>> for them; for example:
>> ===
>> @ImplicitSafeNavigation class Foo {
>> static foo(a,b,c,d,e) {
>>*c[d]<<e.bax() // just e.g.; would work with *any*
>> expression which NPEs today
>> }
>> }
>> assert null ==,null,null,null,null)
>> ===
>> I wonder whether this enhancement would be possible to implement in
>> some forthcoming Groovy release? Myself, I believe it would help
>> tremendously.
>> If feasible, then it is for a further discussion whether in the scope
>> of this annotation
>> (a) a safe-navigation syntax (“foo?.bar”) should be ignored as superfluous;
>> (b) or, whether in this scope it should reverse the behaviour to
>> trigger an NPE anyway;
>> (c) or, whether it should be ignored as (a), and aside of that it
>> would be worth the effort (and technically possible) to add another
>> syntax to force NPE over a particular sub-expression (e.g.,
>> “foo!.bar”).
>> Thanks and all the best,
>> OC
>> [*] The name might not be quite apt, for propagating a null is not
>> inherently safer than NPEing; those are simply two different
>> approaches, both of which serve best in different circumstances. A
>> better name would be something like “null-propagating” or “non-NPE”
>> mode, I guess. Myself, I don't think we should change the name though,
>> for all are used to it.

View raw message