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 22:53:37 GMT

> On 15 Aug 2018, at 12:28 AM, Jennifer Strater <> wrote:
> First, I agree with Paul and Andres that it would be nice to see how well this works
outside of groovy core. Hopefully, someone here can help you make it a reality.

The main problem I can (perhaps mistakenly) see there is that — far as I can say — the
only viable way to make it work in the current Groovy is the Null metaclass trick (with some
ASTT side support). ASTT-only solution, at least when I have tried myself with my limited
extent of knowledge, proved rather at the unfeasible side.

The self-evident drawback of the Null metaclass trick is that it can't be — again, far as
I can say and far as my knowledge goes — easily made class- or even method- or even block-granular,
based on annotations. That's no problem for me, who don't want to see any NPE ever; very grave
problem though for a general audience, which would presumably want to switch the null-propagating
“safe” mode on just intermittently and only for clearly marked parts of the code.

> In addition, I would really appreciate it, if, in the future, you did not use 'gentlemen'
to address the entire mailing list.

Oh, I do apologise to all the ladies. I just came here from an extensive and prolonged debate
in another (private) maillist where there really happen to be gentlemen only, and sorta unthinkingly
I just went on using the same address I used in there. No offence meant!

Thanks and all the best,

> On Tue, Aug 14, 2018 at 1:28 PM, 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
>  }
> }
> 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