groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From h...@abula.org
Subject Re: suggestion: ImplicitSafeNavigation annotation
Date Wed, 15 Aug 2018 07:09:40 GMT
Den 2018-08-15 00:28, skrev Jennifer Strater:
> Hi OC,
> 
> 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.
> 
> In addition, I would really appreciate it, if, in the future, you did
> not use 'gentlemen' to address the entire mailing list.

Good point, and not very gentleman-like! Will 'ladies and gentlemen do'? 
:-)

H2
Gentleman, hopefully...

> Best,
> Jenn
> On Tue, Aug 14, 2018 at 1: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