groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OC <...@ocs.cz>
Subject Re: Safe index for Groovy 3
Date Wed, 09 Nov 2016 17:40:05 GMT
Cédric,

On 9. 11. 2016, at 16:37, Cédric Champeau <cedric.champeau@gmail.com> wrote:

> Not throwing an NPE doesn't mean you are safe.

Absolutely. Myself, I do not like the name, but it is a Groovy thing -- you (unlike me) should
probably know who decided to name the ?. thing a “safe navigation”. In my personal vocabulary
it is neither safe, nor a navigation; but for consistency, I just keep using the vocabulary
of yours.

> It means it doesn't throw errors, but you gave away on semantics. NPEs are often blamed,
but they correspond to developer errors.

Quite the contrary. The only thing they do is promoting bloatware and ugly boilerplate, namely,
zillions of “if (foo!=nil) foo.bar()” etc. in Java code.

The Groovy way of “foo?.bar()“ is much better, but still far from perfect.

The perfect way is simply “foo.bar()” for the same behaviour.

> Only the developer knows if null is relevant or not.

Precisely, that's the very reason for my suggestion. In those very rare cases where it makes
sense to check for null inside of an expression (instead of, as in 99.99 % of cases, at the
result), he explicitly checks and takes an appropriate course, instead of getting an unwanted,
surprising and potentially disastrous NPE.

> I'm totally -1 on this.

Pity, it would improve Groovy considerably.

(Along with another possibility to switch off -- preferrably through an annotation, too --
the just as terrible GroovyCastException, which leads to very ugly contraptions instead of
clean, concise and stable proxying; but that's another story, and based on some older debates
with Jochen I am afraid this would not be possible at all, for the exception probably is caused
by JVM and can't be dodged anyhow.)

Thanks and all the best,
OC

> 2016-11-09 16:33 GMT+01:00 OC <ocs@ocs.cz>:
> Daniel,
> 
> On 9. 11. 2016, at 15:49, Daniel Sun <realbluesun@hotmail.com> wrote:
> 
> >       IMHO, 'full safe' switch  will change the semantic of existing '.'
> 
> Absolutely.
> 
> > which may reduce the maintainability and readability of program
> 
> Quite the contrary.
> 
> As always, I might be overlooking something of importance, but it seems to be whomever
whose code relies on NPE would never use that switch [*].
> 
> On the other hand, for us who *NEVER* want to see *ANY* NPE, and at the moment, are thus
forced to an ugly mess of special null metaclasses and ASTTs, it would help tremendously,
making the code considerably more stable and safer (e.g., since those ASTTs tend to clash
with traits, and who know with what else in future).
> 
> Now, [*] I have (just again!) forgot the terrible Java-induced approach of building whole
project, instead of compiling each source file separately, as it always used to be with decent
languages. Dang. This means my suggested approach of a compiler switch would indeed get dangerous
with sources, added to project, but maintained by another party -- which sources might depend
on the NPE, and the compiler switch would cause precisely the problems you mention. Therefore,
a compiler switch is actually out of question.
> 
> Hmmm.... what about a class-level annotation, which would direct the compiler (and possibly
runtime) to behave appropriately? Something like
> 
> @AlwaysSafe class foo {
>   def bar(a,b,c,d) { // this method never NPEs; if any argument is null, it simply returns
null
>     a.foo+b+c[d] // and so forth with any other operation
>   }
> }
> 
> That would be, in my personal opinion, completely safe, and would help a lot?
> 
> Thanks and all the best,
> OC
> 
> 
> 


Mime
View raw message