Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@groovy.apache.org
MIME-Version: 1.0
In-Reply-To: <6636D008-F782-4AAC-B4A7-0AE86F7C271E@ocs.cz>
References: <1478621298812-5736558.post@n5.nabble.com> <8F0E7347-05E3-48A1-A4D4-8E4873305C11@ocs.cz>
 <1478702991495-5736597.post@n5.nabble.com> <6636D008-F782-4AAC-B4A7-0AE86F7C271E@ocs.cz>
From: =?UTF-8?Q?C=C3=A9dric_Champeau?= <cedric.champeau@gmail.com>
Date: Wed, 9 Nov 2016 16:37:50 +0100
Message-ID: <CADQzvmmXk0ms=xdk7Mxk2LvVkC3R2whGn8wETN7TomFH9FNVSQ@mail.gmail.com>
Subject: Re: Safe index for Groovy 3
To: dev@groovy.apache.org
Cc: Daniel Sun <realbluesun@hotmail.com>, dev@groovy.incubator.apache.org
Content-Type: multipart/alternative; boundary=001a11376f92322d8c0540e00a82
archived-at: Wed, 09 Nov 2016 15:38:01 -0000

--001a11376f92322d8c0540e00a82
Content-Type: text/plain; charset=UTF-8

Not throwing an NPE doesn't mean you are safe. It means it doesn't throw
errors, but you gave away on semantics. NPEs are often blamed, but they
correspond to developer errors. Only the developer knows if null is
relevant or not. I'm totally -1 on this.

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

--001a11376f92322d8c0540e00a82
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Not throwing an NPE doesn&#39;t mean you are safe. It mean=
s it doesn&#39;t throw errors, but you gave away on semantics. NPEs are oft=
en blamed, but they correspond to developer errors. Only the developer know=
s if null is relevant or not. I&#39;m totally -1 on this.</div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">2016-11-09 16:33 GMT+01:00 =
OC <span dir=3D"ltr">&lt;<a href=3D"mailto:ocs@ocs.cz" target=3D"_blank">oc=
s@ocs.cz</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Daniel,<br>
<span class=3D""><br>
On 9. 11. 2016, at 15:49, Daniel Sun &lt;<a href=3D"mailto:realbluesun@hotm=
ail.com">realbluesun@hotmail.com</a>&gt; wrote:<br>
<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0IMHO, &#39;full safe&#39; switch=C2=A0 will =
change the semantic of existing &#39;.&#39;<br>
<br>
</span>Absolutely.<br>
<span class=3D""><br>
&gt; which may reduce the maintainability and readability of program<br>
<br>
</span>Quite the contrary.<br>
<br>
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 [*].<br>
<br>
On the other hand, for us who *NEVER* want to see *ANY* NPE, and at the mom=
ent, are thus forced to an ugly mess of special null metaclasses and ASTTs,=
 it would help tremendously, making the code considerably more stable and s=
afer (e.g., since those ASTTs tend to clash with traits, and who know with =
what else in future).<br>
<br>
Now, [*] I have (just again!) forgot the terrible Java-induced approach of =
building whole project, instead of compiling each source file separately, a=
s it always used to be with decent languages. Dang. This means my suggested=
 approach of a compiler switch would indeed get dangerous with sources, add=
ed to project, but maintained by another party -- which sources might depen=
d on the NPE, and the compiler switch would cause precisely the problems yo=
u mention. Therefore, a compiler switch is actually out of question.<br>
<br>
Hmmm.... what about a class-level annotation, which would direct the compil=
er (and possibly runtime) to behave appropriately? Something like<br>
<br>
@AlwaysSafe class foo {<br>
=C2=A0 def bar(a,b,c,d) { // this method never NPEs; if any argument is nul=
l, it simply returns null<br>
=C2=A0 =C2=A0 a.foo+b+c[d] // and so forth with any other operation<br>
=C2=A0 }<br>
}<br>
<br>
That would be, in my personal opinion, completely safe, and would help a lo=
t?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
Thanks and all the best,<br>
OC<br>
<br>
<br>
</div></div></blockquote></div><br></div>

--001a11376f92322d8c0540e00a82--