Re: PL/Java new build plugin

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