|
Posted by Ted on April 24, 2008, 12:52 am
Please log in for more thread options
wrote:
> On Wed, 23 Apr 2008 18:24:31 -0700 (PDT),
>
>
> >> =A0[ on the conversion of NULL fields to <undefined> ]
>
> >> > This would be a useful tidbit to add to the documentation. =A0I hadn'=
t
> >> > expected a mature library like DBI to behave like this.
>
> >> Well, it is the most DWIM way of representing NULL values in perl.
>
> > As I explained to Xho, it is wrong. =A0My understanding of undefined in
> > Perl was to relate it to uninitialized values in Java or C++. =A0You
>
> Your whole argument seems to be based on this assumption. I'm pretty
> sure that that assumption is wrong. Could you tell us what that
> assumption is based on? And if that was the only reason for the undef
> value to exist, why does the undef function exist?
>
OK. You're absolutely right.
I got my understanding of undefined from the book, published by
O'Reilly, "Programming Perl" by Larry Wall, Tom Christiansen and
Randal Schwartz. On page 155, about half way down the page talking
about the function defined, I see "A scalar that contains no valid
string, numeric, or reference value is known as the undefined value,
or undef for short. Many operations return the undefined value ender
exceptional conditions, such as end of file, uninitialized variable,
system error, and such. This function allows you to distinguish
between an undefined null string and a defined null string when you're
using operators that might return a real null string." From what I'm
reading here, it seems my understanding of undefined is not far off
the mark.
> Comparing it to null in Java or NULL in C or C++ is probably a good
> analogy. In all those cases the value is a special one that carry a
> meaning that is close to the null value in SQL: A value that is not part
> of the normal range of values. The fact that nulls in SQL have special
> 'handling' does not change that. If Jave or C has set operations, then
> they would need to deal with null in very much the same way, and if Perl
> has them, it would probably do similar things to undef.
>
Here you're confusing me. I agree, given what Wall et al. wrote about
it, comparing undefined to null in Java or C/C++ is a decent analogy,
but not exact. It is more correct to relate it to variables or
identifiers that have been declared but not yet initialized. In fact,
Wall et al. explicitly relate it to uninitialized variables (the very
first sentence I quoted above). One can, in C++, forward declare a
class, which then allows pointers to the class to be declared, but all
one knows, until the definition of the class is provided, is that the
class exists, and so a pointer to an instance of the class can be
declared, but it can't really be used with out the defintion.
Similarly, you can declare functions with prototypes, which can be
called, but you better be sure to link to an object file that provides
the definitions or your linker will complain. But bugs where a
variable is used before it is initialized can be a nightmare to track
down because the problem may only manifest itself sometimes. NULL, in
C++, is specifically a value of 0 given to a pointer. An
uninitialized variable can contain random bits, though the standard
was changed so that you could use a slightly different declaration
that initializes a pod variable to 0. A variable in Java is given a
value of null until it is given an instance of the type of variable it
was defined to represent. It is also clear from what Wall et al. said
that undef can play a role similar to the 'end' iterator defined for
all of the containers in the standard C++ library. I am not exactly
happy with that notion because it is again a very different concept
from that of a null pointer or an uninitialized variable, but it is
admittedly functional. Allowing a programming language to be markedly
multivocal is a recipe for confusion, at least without extensive and
pedantic documentation.
But ALL of these concepts are very different from the idea of NULL in
SQL. For example, The book, from Osborne, "SQL: The complete
reference" by James Groff and Paul Weinberg, described it as referring
to data that is missing, unknown, or don't apply. There is some
debate about it with some advocating avoiding it at all costs and
others avocating wide use of it and even suggesting the term be
extended to have different null indicators to allow one to distinguish
between, e.g. data that is unknown vs data that doesn't apply. While
NULL in SQL is different from numeric or string data, I see nothing in
the idea that indicates it is a value that is not part of the normal
range of values. In a table that handles returns on investment for
exchange traded funds for various time frames with columns
representing monthly, quarterly, annual and five year returns, the
column containing five year returns would probably have a model value
of NULL, since the majority exchange traded funds are younger than
five years old. In this specific case, the idea is that a five year
return is not applicable to funds that are not yet five years old.
Yet, the numbers of exchange traded funds has been continually
increasing and it is just a matter of time until that column IS
applicable.
I see nothing similar between the idea of NULL in SQL and either null
or undefined in the other languages.
Both Java and C++ have containers that support set theoretic
operations. But I see nothing specific to those containers and the
algorithms they support that relates to either null or undefined in C+
+ or Java, and I'd have to think about the extent to which they
provide a concept comparable to the idea of NULL in SQL. I can see,
though, how one could easily emulate the idea of NULL as found in SQL
using these containers with a UDT defined to be able to assume a
"null" value and to behave the way NULLs behave in SQL when they have
the null value defined for them. Doing it this way, though, has
virtually nothing in common with the idea of null as it exists in
either C++ or java. Unless you want to relate the SQL idea of NULL to
the empty set, I do not see any necessary relatin between programming
set theoretic algorithms and the idea of null. But if you see the
idea of the empty set as being integral to the idea of null as it
exists in SQL, then the relation with either null or undefined in C++,
Java or Perl becomes even more distant because the relevant containers
in C++ and Java make no direct use of nulls in handling empty sets as
far as I can see. In both cases, the containers have member functions
that return true if the set is empty and fals otherwise.
> SQL NULL maps, IMO, very well to Perl undef.
>
Unless you can explain how the ideas can be reconciled, I can not
agree. I see nothing in common between them.
Thanks
Ted
|
|
Posted by Jürgen Exner on April 24, 2008, 1:17 am
Please log in for more thread options
>It is more correct to relate it to variables or
>identifiers that have been declared but not yet initialized.
No. An unitialized variable can have any value. Mabye a left-over from a
previous run, maybe some temporary result that was computed a while ago
and left on the stack or whatever. It is mostly a concession to the
laziness of programmers as well as some security concerns that nowadays
runtime environments initialize declared variables with 0 or some
similarly reasonable default.
Undef on the other hand is a well defined, very specific value, which
you can even set explizitely and test against.
You cannot 'reuninitialize' a variable in e.g. C after it was assigned a
value.
jue
|
|
Posted by Ted on April 24, 2008, 7:56 am
Please log in for more thread options > >It is more correct to relate it to variables or
> >identifiers that have been declared but not yet initialized.
>
> No. An unitialized variable can have any value. Mabye a left-over from a
> previous run, maybe some temporary result that was computed a while ago
> and left on the stack or whatever. It is mostly a concession to the
> laziness of programmers as well as some security concerns that nowadays
> runtime environments initialize declared variables with 0 or some
> similarly reasonable default.
>
> Undef on the other hand is a well defined, very specific value, which
> you can even set explizitely and test against.
> You cannot 'reuninitialize' a variable in e.g. C after it was assigned a
> value.
>
Yes, an uninitialized variable can contain random bits, or garbage,
for whatever reason, but If you are going to say undef is a specific
value, how do you account for Wall et al writing "A scalar that
contains no valid string, numeric, or reference value is known as the
undefined value, or undef for short." That sure looks like a
description of a variable that has not yet been initialized.
In all of my code, in whatever language, I always initialize my
variables to 0, or some other reasonable default, as a matter of
course. Doing so prevents nasty surprises that may result from using
a variable that has not been initialized and is easily tested for.
That seems quite different from the idea of someting being undefined.
Ted
|
|
Posted by Joost Diepenmaat on April 24, 2008, 8:14 am
Please log in for more thread options
> Yes, an uninitialized variable can contain random bits, or garbage,
> for whatever reason, but If you are going to say undef is a specific
> value, how do you account for Wall et al writing "A scalar that
> contains no valid string, numeric, or reference value is known as the
> undefined value, or undef for short." That sure looks like a
> description of a variable that has not yet been initialized.
But it *has* been initialized. All scalars that aren't assigned a value
are initialized to "undef", which *is* a value (the quote explicitely
states that) and corresponds most closely to the null value in C++ /
Java et al.
> In all of my code, in whatever language, I always initialize my
> variables to 0, or some other reasonable default, as a matter of
> course. Doing so prevents nasty surprises that may result from using
> a variable that has not been initialized and is easily tested for.
> That seems quite different from the idea of someting being undefined.
That's fine in C, but in perl the interpreter already does this for you
as I described above. Of course that assumes the undef value is actually
a useful default for your algorithm.
Seems to me you're taking the word "undefined" too literal (for
perl). It's not undefined as in "the consequences of doing X are
undefined". It's undefined as in "has the default (null) value because
it's not been assigned anything else".
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
|
|
Posted by Ted on April 24, 2008, 9:03 am
Please log in for more thread options > > Yes, an uninitialized variable can contain random bits, or garbage,
> > for whatever reason, but If you are going to say undef is a specific
> > value, how do you account for Wall et al writing "A scalar that
> > contains no valid string, numeric, or reference value is known as the
> > undefined value, or undef for short." =A0That sure looks like a
> > description of a variable that has not yet been initialized.
>
> But it *has* been initialized. All scalars that aren't assigned a value
> are initialized to "undef", which *is* a value (the quote explicitely
> states that) and corresponds most closely to the null value in C++ /
> Java et al.
>
> > In all of my code, in whatever language, I always initialize my
> > variables to 0, or some other reasonable default, as a matter of
> > course. =A0Doing so prevents nasty surprises that may result from using
> > a variable that has not been initialized and is easily tested for.
> > That seems quite different from the idea of someting being undefined.
>
> That's fine in C, but in perl the interpreter already does this for you
> as I described above. Of course that assumes the undef value is actually
> a useful default for your algorithm.
>
> Seems to me you're taking the word "undefined" too literal (for
> perl). It's not undefined as in "the consequences of doing X are
> undefined". It's undefined as in "has the default (null) value because
> it's not been assigned anything else".
>
> --
> Joost Diepenmaat | blog:http://joost.zeekat.nl/| work:http://zeekat.nl/
Fair enough. Then what Wall et al wrote could have been improved had
they provided a little extra detail.
But this still seems quite different to what NULL means in SQL. How
would you explain the rationale for that mapping? Abigail has already
explained the reason for my surprise at this.
Thanks
Ted
|
| Similar Threads | Posted | | Multiple Inheritance: mixed base class refs (hash, array) | April 29, 2005, 2:29 am |
| FAQ 9.3: How can I get better error messages from a CGI program? | December 5, 2004, 6:03 pm |
| FAQ 9.3: How can I get better error messages from a CGI program? | December 29, 2004, 12:03 pm |
| FAQ 9.3 How can I get better error messages from a CGI program? | March 25, 2005, 12:03 pm |
| FAQ 9.3 How can I get better error messages from a CGI program? | June 4, 2005, 5:03 am |
| FAQ 9.3 How can I get better error messages from a CGI program? | September 23, 2005, 4:03 pm |
| FAQ 9.3 How can I get better error messages from a CGI program? | November 29, 2005, 5:03 am |
| FAQ 9.3 How can I get better error messages from a CGI program? | September 17, 2006, 9:03 pm |
| FAQ 9.3 How can I get better error messages from a CGI program? | March 21, 2007, 3:03 am |
| FAQ 9.3 How can I get better error messages from a CGI program? | November 11, 2007, 9:03 pm |
|
XML Sitemap