|
Posted by Peter J. Holzer on April 26, 2008, 5:53 am
Please log in for more thread options
> But null values in SQL are not the same thing as undefined or
> uninitialized values in any other language I know.
Neither are perl undef values the same thing as uninitialized values in
any other language I know.
> In any RDBMS I have worked with, null is a legitimate value that can
> be given to a specific column in a specific row, and it has a very
> specific meaning in a database.
In Perl, undef is a legitimate value that can be given to a scalar, and
it has a very specific meaning in Perl.
> Any SQL programmer knows how to handle nulls, what can and can not be
> done with them, &c.
Any Perl programmer knows how to handle undefs, what can and can not be
done with them, &c.
> That is very different from programming errors where a variable has
> been defined and then used before it has been given a value.
That is very different from programming errors where a variable has been
defined and then used before it has been given a value.
There are no uninitialized variables in Perl. If the programmer doesn't
explicitely initialize a variable, it is implicitely initialized to
undef. This is similar to C implicitely initializing all variables of
static duration to 0 (of the appropriate type). C doesn't initialize
automatic variables, but Perl does.
(The warning about an "uninitialized value" is misleading, IMHO. It
should say "undefined value", or simply "undef". But it is unlikely to
change)
> So I maintain this IS a DBI issue, and there ought to be functionality
> provided within DBI to handle the processing of recordsets, including
> printing them, that can handle null values in a rational manner
> without generating spurious warnings.
There is no unambiguous way to convert a null value to a string. For
every string you choose, it would also be a valid string value.
Therefore it is better to leave that to the programmer.
> At a minimum the DBI documentation ought to say somethng
> about users needing to implement their own processing to handle null
> values when that is not available.
It does. There's a whole section entitled "NULL Values" in perldoc DBI.
> The real error here is that, if I am to believe Ted, that nulls are
> treated as undefined in the DBI translation, and this is plain wrong.
> On the daatabase side, nulls have a specific meaning (and as you well
> said, further on, that meaning is different from that of an empty
> string),
undef also has a specific meaning and that is different from an empty
string. The meaning is not exactly the same as that of SQL null, but I
doubt you'll find two languages where "null" or "nil" or "undef" or
whatever it is called has exactly the same meaning. Most languages have
the concept of "a missing, unknown or undefined value", but the details
differ.
> and DBI ought to at least provide a means of handling them
> correctly from the perspective of a database programmer.
The means are there. You get a specific value which can be distinguished
from any non-null value. How you handle it is up to you.
> The fact is that if I wanted to represent, in a C++ or Java program,
> the idea represented by null in SQL, I could write a class that
> represents that idea and give me the kinds of behaviours I'd require
> of it; something far richer than anything possible with the null
> keywords in either C++ or java.
You can do the same thing in Perl.
> Therefore, I could do precisely the same thing in Perl, if need be.
Ah, yes. So you realized that yourself. What's stopping you?
> I repeat yet again, it is wrong to think of this as a perl issue,
> rather than an issue of a deficiency in the DBI library.
I see that as a feature, not a deficiency. Why should the DBI force a
slow, clunky interface on me if a lean, fast one suffices in 99% of all
cases? DBI is slow enough as it is. It doesn't have to be slowed down
artificially.
> The mistake here is to assume this is a perl issue. Perl, like Java
> and C++ and FORTRAN and a host of other programming languages, is
> Turing complete, so anything that can be done in any one of them can
> in principle be done in any of the others. Surely you know that JDBC
> is to Java as DBI is to Perl.
Yes. And there's the Java way and the there's the Perl way (Ok, there
is more than one Perl way, but you know what I mean). JDBC presents an
interface that is natural to a Java programmer and DBI presents an
interface that is natural to a Perl programmer. You shouldn't expect
them to be identical.
hp
| 
XML Sitemap