groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: suggestion: ImplicitSafeNavigation annotation
Date Tue, 14 Aug 2018 11:49:49 GMT
Sounds like a good candidate for macro methods, maybe extending this:
https://github.com/touchez-du-bois/akatsuki/blob/master/src/main/java/org/jggug/magica/akatsuki/NullSafeMacro.java#L21

I'd be inclined to wait for some macro libraries to be published outside
groovy core to start with and see what usage they get.
If they are popular, we can easily bring them into core perhaps with some
polish/tweaks gained from usage insights.
Once introduced though, it's a little harder to evolve/deprecate/remove
given backwards compatibility etc.

Cheers, Paul.


On Tue, Aug 14, 2018 at 9:28 PM ocs@ocs <ocs@ocs.cz> wrote:

> 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) {
>    a.bar+b*c[d]<<e.bax() // just e.g.; would work with *any* expression
> which NPEs today
>  }
> }
> assert null == Foo.foo(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.
>
>

Mime
View raw message