> If you want different semantics for undef then use a pragma, that is
> what pragmas are for.
> However I would suggest that many, including myself, would not like
> to see perls values have yet another state of null
Here's my concern about changing the meaning of undef. Convince me this
is not a concern and I'll change the RFC appropriately.
undef has a very well-defined (ha!) Perl meaning: that something is
undefined. null has a very well-defined RDBMS meaning: that something is
unknown. Perl allows you to add and concatenate stuff to undef, because
that value can be coerced into 0 and "" without harm. The concept of
null does not allow you to do this, because a null value is unknown: it
may be undef, or 0, or -3.2e14, or "bob", but you *don't know*.
Using the proposed tristate pragma does not strike me as any better -
in fact, worse - than adding null() because you are now changing the
meaning of fundamental Perl operations. You're *still* introducing "yet
another state of null", but to do so you're conflating undef and null,
which are themselves different concepts. For example, assuming this
code:
$name = undef;
print "Hello world!" if ($name eq undef);
The same operation would print "Hello world!" in one circumstance, but
nothing under the tristate pragma. This is just as dangerous as having a
pragma like so:
use 'zeroistrue';
$num = 0;
print "Got data" if ( ! $num );
Where the above would print out "Got data" normally, but not under the
pragma.
That's my concern, in a nutshell. Convince me this is invalid (similar
Perl precedent would help) and I'll change the RFC into a "use tristate"
pragma.
-Nate
