MIME-Version: 1.0
References: 
 <CAASLQ4Mva7dAXiS_c9OLhV4VzNHF=XNKJosuS5gtZTB6b4TW1Q@mail.gmail.com>
 <5EFA6C22.8060006@anastigmatix.net> <5EFC18D9.3090108@anastigmatix.net>
 <CAASLQ4N0KeUx8PaJMKbHWiVtLvBo3QNACdHgOyk72q30976d+g@mail.gmail.com>
 <5EFD41B1.30009@anastigmatix.net>
 <CAASLQ4NvfJz8VQQFU8mKkY4RabiVQesxdbkudk5Cf24Tm9BixQ@mail.gmail.com>
 <5EFE0A4D.8060402@anastigmatix.net>
 <CAASLQ4M3+XNBYiHMg32X6poY25eMbvMC5MHbA48pt30QK8nAww@mail.gmail.com>
 <5F0125BC.5000609@anastigmatix.net>
 <CAASLQ4PtGSS-OP9k_740EBdyT1bVmDi1PUndn1ZNWzyJDRQkMA@mail.gmail.com>
 <5F0172D7.3000708@anastigmatix.net>
 <CAASLQ4NXzEttesB48wxD_wvR5_rNDvXZkKCmNELn247+W_vrMw@mail.gmail.com>
 <5F02122C.7040905@anastigmatix.net>
 <CAASLQ4NTYp42EY1=nnKPRAr6VV-KpQ=hueQn-jHZsEebp4cAaQ@mail.gmail.com>
 <5F021785.905@anastigmatix.net>
 <CAASLQ4OCh2ybECbfJQ5UgSo4r-UxRcmPPhqjrGpEZ=ZPdURNMg@mail.gmail.com>
 <5F021A20.1050903@anastigmatix.net>
 <CAASLQ4MWn3BjiZpijXEjd3sYaeuQnFffafZYe9XWnV8PPXv1nQ@mail.gmail.com>
 <5F02340C.7030002@anastigmatix.net>
In-Reply-To: <5F02340C.7030002@anastigmatix.net>
From: Kartik Ohri <kartikohri13@gmail.com>
Date: Mon, 6 Jul 2020 01:52:32 +0530
Message-ID: 
 <CAASLQ4NOq2FcTvp1hB-kTnJZgxfRP=u20gfQT=tgpvBq+9Ac-w@mail.gmail.com>
Subject: Re: PL/Java new build plugin
To: Chapman Flack <chap@anastigmatix.net>
Cc: pljava-dev@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000004b7e0505a9b785ea"
Precedence: bulk

--0000000000004b7e0505a9b785ea
Content-Type: text/plain; charset="UTF-8"

>
> But it is a lot of explaining to have to do in a situation where
> there is an alternative that doesn't have the problem, and not only
> is it easy, it is the way the code did work before you changed it.
>
> Does that make sense?
>
Yes, it does. I'll fix this immediately.


> ---
>
> I hope this doesn't sound unkind; it seems like you had a belief
> "the OS doesn't allow line separators in pathnames" that turned out
> not to be correct.

Certainly, I did not know that line separators were allowed in path names
and hence made this error. I will keep this in mind from now on.


> Happens all the time. When something like that happens
> to me, I go through about five stages of processing it:


>
1. Hmm, I believed X was true and it isn't. Bummer.
>
> 2. Can I remember roughly how long I have believed X was true?
>
> 3. Have I written anything else in that time where I might have used
>    the belief that X was true? Any of it worth going back to review
>    or add test cases?
>
> 4. Can I remember from what source I first got the idea X was true?
>
> 5. Can I remember any other things Y, Z, ... that I learned from
>    the same source?  Would this be a good time to check Y, Z, ... also?
>
> ---
>
> The case of line separators in pathnames makes a prime example of something
> that is no problem as far as the core OS is concerned, but is very widely
> cautioned against /because/ it may often trigger failures in, ahem,
> userland
> code that makes too many assumptions.
>
> And that is a very good reason for people who are using a system, and
> choosing how to name things, to be cautious in that way.
>
> At the same time, it is not a good reason for people who write code
> to write the kind of code that makes such caution necessary.
>
> This reduces to Jon Postel's robustness principle from RFC 760, "be
> conservative in what you do, be liberal in what you accept from others."
>
Thanks for the detailed advice. It will help me to write better code.

--0000000000004b7e0505a9b785ea
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">But it is a lot of explaining to have to do in a situati=
on where<br>
there is an alternative that doesn&#39;t have the problem, and not only<br>
is it easy, it is the way the code did work before you changed it.<br>
<br>
Does that make sense?<br></blockquote><div>Yes, it does. I&#39;ll fix this =
immediately.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">---<br>
<br>
I hope this doesn&#39;t sound unkind; it seems like you had a belief<br>
&quot;the OS doesn&#39;t allow line separators in pathnames&quot; that turn=
ed out<br>
not to be correct. </blockquote><div>Certainly, I did not know that line se=
parators were allowed in path names and hence made this error. I will keep =
this in mind from now on.</div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">Happens all the time. When something like that happe=
ns<br>
to me, I go through about five stages of processing it:</blockquote><div></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">=C2=A0<br></blockquot=
e><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">
1. Hmm, I believed X was true and it isn&#39;t. Bummer.<br>
<br>
2. Can I remember roughly how long I have believed X was true?<br>
<br>
3. Have I written anything else in that time where I might have used<br>
=C2=A0 =C2=A0the belief that X was true? Any of it worth going back to revi=
ew<br>
=C2=A0 =C2=A0or add test cases?<br>
<br>
4. Can I remember from what source I first got the idea X was true?<br>
<br>
5. Can I remember any other things Y, Z, ... that I learned from<br>
=C2=A0 =C2=A0the same source?=C2=A0 Would this be a good time to check Y, Z=
, ... also?<br>
<br>
---<br>
<br>
The case of line separators in pathnames makes a prime example of something=
<br>
that is no problem as far as the core OS is concerned, but is very widely<b=
r>
cautioned against /because/ it may often trigger failures in, ahem, userlan=
d<br>
code that makes too many assumptions.<br>
<br>
And that is a very good reason for people who are using a system, and<br>
choosing how to name things, to be cautious in that way.<br>
<br>
At the same time, it is not a good reason for people who write code<br>
to write the kind of code that makes such caution necessary.<br>
<br>
This reduces to Jon Postel&#39;s robustness principle from RFC 760, &quot;b=
e<br>
conservative in what you do, be liberal in what you accept from others.&quo=
t;<br></blockquote><div>Thanks for the detailed advice. It will help me to =
write better code.=C2=A0</div></div></div>

--0000000000004b7e0505a9b785ea--