Sam Tregar wrote:
> 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.
I'm glad you like Perl's undef. Use it where you like.
> 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'm sorry you don't care for SQL's NULL. However, you seem to understand it,
even though you use unflattering terminology to describe it, which is good.
I'd hate for you to write DB interface code without understanding it.
> 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.
They are different. Neither is a mistake.
> Perhaps you could show an example using DBI where having NULLs mapped to
> undef is actually a problem?
If one (you wouldn't, I suspect) wanted to write expressions in Perl that had
the same semantics as expressions in SQL, which could come in handy for
further manipulating data obtained from SQL, then mapping NULLs to undef
doesn't make that easier. You have to rewrite all zillion op-codes,
prechecking for undef on all operands and handling the semantics required.
This is clearly possible, but is confusing. This could possibly be done with
objects, but would be slow at best.
It is not a problem if all you do with DB data is retrieve and/or store. It
is only a problem if you want to do DB style manipulations of the data.
> Do you ever want to just blithely use a NULL
> in an expression and not get a warning out of it?
Absolutely. The semantics of NULL neither require nor desire warnings. If
you want warnings, use strict and undef. If you want unknown value
propagation, NULLs fill the bill.
Note that IEEE floating point defines a multitude of NULL values with
NULL-like semantics, but not an undef, if you want another precedent (I'm
referring to NaN values here).
> Is this really about
> skipping error checking code on the results of SELECTs?
Who would want to do that?
--
Glenn
=====
Even if you're on the right track,
you'll get run over if you just sit there.
-- Will Rogers
_______________________________________________
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
