In Perl5, the following values are FALSE: undef, '0', 0, and ''.
What you fail to note is that each of these is false for a reason. undef is false so that you can test an object for truth; if it is undef it obviously contains no data, so it's false. 0 is false so that you can test numbers for truth. '' is false so that you can test strings for truth. The really special case is '0', which is false for arcane (but very sensible) reasons.
Okay, so it's binary data. So is "0" and 0, if you look at it that way.
The difference here is that there is no normal circumstance wherein you would get a binary null if there's no data. The only situation I can think of that even comes close would be if you were reading null-terminated strings from a C or Assembler program out of some kind of binary file, and in that case you'd almost certainly split on binary null, so you'd get "" if there were no data in a given string, and that would be false as per the existing rules.
Perl is a pragmatic language; things are true (or false) for good reasons, so that you can do various things easily.
I realize the internal representations are different, but the programmer
shouldn't have to care about that.
When are you going to run into binary nulls if you're NOT mucking about with internal representations?
> I just figure that if my bit of $data =
contains one byte, and I'm checking that $data for boolean truth,
You can always check the number of bytes (or characters), and it'll be false in boolean context if it's zero: mumblefrotz(\$data) while length $data;
So my question is this, with apology for the ramble.... aside from P6's other changes, is a single null byte of binary data still going to register as TRUE, or will it now be what seems to me the more sensible FALSE?
As I understand it, the addition of properties in Perl6 (See the Apocalypse 12 article) allows for even undefined values to be true if you choose to make them so.
