Daniel,
On 9. 11. 2016, at 15:49, Daniel Sun <realblue...@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
