Re: suggestion: ImplicitSafeNavigation annotation

[h2gr]

Den 2018-08-14 14:25, skrev ocs@ocs:
H2,
On 14 Aug 2018, at 1:38 PM, h...@abula.org 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 “a.plus(b)”, but
for the syntactic inconvenience:

http://docs.groovy-lang.org/latest/html/documentation/#Operator-Overloading

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.

As a matter of personal preference, this is fine with me. If you write 
“a?.plus(b)” you are explicitly going out on a limb, and it is 
explicitly visible what you're doing.

However, “a+b” should work as one would expect. What might one expect? I 
guess that something to vote over, but I propose that at the very least, 
one should not expect unexpected errors or errors that are hard to catch 
or test. It's better to catch null-related errors where they occur than 
somewhere else because an entire expression gets evaluated to null 
instead of throwing an exception.

If you want a shorthand notation for “a?.plus(b)” I'd say “a?+b” was 
more consistent (but I am by no means suggesting it).

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 :)

Of course not, but it would be impossible to know by looking at just the 
code how it is going to behave.

Wouldn't this create potential problems when the code finds its way into 
different project by means of dependencies?



Thanks and all the best,
OC

Ditto! :-)

H2

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) {
  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.