groovy-dev mailing list archives

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