On 20 Sep 2000, Perl6 RFC Librarian wrote:
> The absence of a C<null> concept and keyword in Perl makes it more
> difficult to interface with relational databases and other medium which
> utilize C<null>. Modules such as C<DBI> must map C<null> to C<undef>,
> which is an imperfect match.
Does it really make it more difficult? I would argue that having NULLs
mapped to undefs is actually better than having real NULLs in Perl. An
undef is a rather concrete and easily dealt with value - simply test with
defined(). Plus, if you're careless enough to try to use it you'll get
warnings in strict mode. That, to me, is basically exactly what I want
from a NULL.
What I don't want is what SQL provides - a total oddball of a value. It
doesn't even equal itself. It spreads like a plague through operations
with *no warnings*. It's hands-down the hardest thing about SQL to learn
to use correctly both because of its inherent nonsensicality and the fact
that different RDBMs handle it differently. You want to add this
misfeature to Perl? No thanks.
I agree that undef and NULL have different semantics. However, this is
clearly SQL's fault and not Perl's. We shouldn't repeat their mistake
just because we occasionally have to interface with their system.
Perhaps you could show an example using DBI where having NULLs mapped to
undef is actually a problem? Do you ever want to just blithely use a NULL
in an expression and not get a warning out of it? Is this really about
skipping error checking code on the results of SELECTs?
-sam
