On Thu, Aug 3, 2017 at 3:29 PM hw <h...@gc-24.de> wrote:
> David Mertens wrote:
> It is nonsense to logically negate a string, and it is nonsense to convert
> undefined values into 'false'.
Negating strings is a well defined operation in Perl 5. The following
values in Perl 5 are false: undef, 0, 0.0, "", "0", and the empty list.
Negation turns any value that is true into a false value (PL_sv_no) and any
value that is false into a true value (PL_sv_yes).
> Either are neither false, nor true.
>
You are coming to Perl 5 with assumptions that do not hold water here. As
I said above (and in earlier emails), there are two strings ("0" and "")
that are false and all other strings are true. The undef value is also
false.
> For undefined values, there is no way of deciding whether they are true or
> false
> because they are undefined.
>
That would be true if Perl 5 used a trinary logic system, but if you peruse
the documentation, you will find no mention of it. The undef value in Perl
5 is not analogous to NULL in SQL. It is merely a sentinel value (sort of
like NULL in C, but with no defined value, so it doesn't take up a value
that could otherwise be used). Perl 5 happily coerces this sentinel value
into 0 or "" depending on context (though it will throw a warning if use
the warnings pragma).
Perl 5 has no boolean type. Instead it has true values and false values.
This works very well in most cases. It would be nearly impossible to
retrofit a boolean type at this point and maintain backwards compatibility,
so the chances of you getting what you want is very unlikely.
If this is a real problem for you, then I suggest you chose a language that
more accurately reflects the way you expect it to work. If you are
required to use Perl 5 by your work, I suggest you find a job that lets you
use the language you want to use. Life is too short to beat your head
against the wall and you don't seem to be listening to the people here.
