Paris Sinclair wrote:
> If
> you need additional semantics than provided by undef, why not make a
> module?
This might be workable. There are some thoughts on that. Personally, I
haven't used that much overloading in Perl to know whether it can be made to
work well enough to completely conform to SQL NULL semantics, which is the
goal of the RFC. I'm not sure that the RFC requires the functionality to be
added to the core, it just wants the functionality to be added, and get
reasonable performance from the result.
> I understand the differences between SQL NULL and Perl undef, I just don't
> understand what defaco general problem is solved with adding it.
Phew! With all the negative "my perl isn't SQL, it's only sh, awk, tr, sed,
grep, and C and I want to keep it that way" comments that this RFC generated,
I'm glad someone understands the differences in the semantics.
One example problem that could be solved more easily with this RFC is this:
when writing a report (I think that's a typical use of Perl) that accesses
data from multiple databases, some further processing of the data within perl,
even joins of data form separate databases, might be needful. Having the NULL
concept available within Perl would make it easier to mimic the joins that can
be done within a database (if only all the data were there).
--
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
