|
Posted by Ted on April 24, 2008, 8:48 am
Please log in for more thread options > On Wed, 23 Apr 2008 21:52:51 -0700, Ted wrote:
> > 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. =A0Many operations return the undefined value ender exception=
al
> > conditions, such as end of file, uninitialized variable, system error,
> > and such. =A0This function allows you to distinguish between an undefine=
d
> > null string and a defined null string when you're using operators that
> > might return a real null string."
>
> Try running the following script to clarify what this means:
>
> #!/usr/bin/perl
> use warnings;
> use strict;
> my $a;
> my $b =3D "";
> print "a is defined\n" if defined($a);
> print "b is defined\n" if defined($b);
>
> Here $b is a "real null string" and $a is undefined.
>
No. $b holds an empty string, and empty strings are not the same thing
as NULL (as defined in either C++ and Java or SQL).
> > Here you're confusing me. =A0I 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. =A0It is more correct to relate it to variables or
> > identifiers that have been declared but not yet initialized.
>
> That's not a good analogy. Again, try the following script:
>
> #!/usr/bin/perl
> use warnings;
> use strict;
> my $b =3D "";
> print "1: b is defined\n" if defined($b);
> undef ($b);
> print "2: b is defined\n" if defined($b);
>
> The undefined value in Perl is assigned to variables but that doesn't
> mean that undefined equals uninitialized.
>
But that is exactly what Wall et al. said about undefined. I learned
much of what I know about Perl from their book, and they said that an
undefined variable is one that does not have a valid string, number or
reference, and that exactly describes a variable that has not yet been
initialized. The empty string is a valid string in all of the
languages I use, and it means something quite different from a SQL
null.
> > Allowing a programming
> > language to be markedly multivocal is a recipe for confusion, at least
> > without extensive and pedantic documentation.
>
> Well, you're going to be confused then - if you feel that way, maybe it's
> better not to learn Perl.
>
Why? Most of what I have seen about perl seems quite well defined.
> > But ALL of these concepts are very different from the idea of NULL in
> > SQL. =A0For example, The book, from Osborne, "SQL: The complete referenc=
e"
> > by James Groff and Paul Weinberg, described it as referring to data that=
> > is missing, unknown, or don't apply.
>
> Which seems to be exactly what the undefined value in Perl is, to me.
>
Then you're using a definition of the term that is quite different
from what Wall et al. wrote about undefined. Where they wrong, or
merely misleading?
> > 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.
>
> Perhaps you can think of Perl's undef as being part of the normal range
> of values, too.
>
In principal I'd have no problem with that, if it weren't for the fact
that Wall et al. described them as referring to variables that were
not initialized. That is, if Perl's undef could be equated to SQL's
concept of null. But as Abigail pointed out, that equation would be
problmatic at best.
> > I see nothing similar between the idea of NULL in SQL and either null or=
> > undefined in the other languages.
>
> That's odd, because the more you talk about SQL's NULL, the more it looks
> like Perl's undefined value to me.
>
Until now, I had seen nothing written about perl that suggested that
Wall et al.'s description of undefined meant anything other than a
reference to variables that had not yet been initialized, and that is
a very different concept from SQL's 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.
>
> You seem to be getting lost in your own verbosity here - you start this
> sentence including Perl and by the end of it you are only talking about
> C++ and Java.
>
This was merely a response to Martien's reference to set theoretic
operations. He'd expressed uncertainty about support C++ and Java
provide for them and implied support for them implied a handling of
SQL nulls in a manner similar to how Perl handles undef.
> > =A0In both cases, the containers
> > have member functions that return true if the set is empty and fals
> > otherwise.
>
> But now, as far as I can figure out, you're not talking about Perl any
> more anyway.
This too was merely a response to Martien's reference to set theoretic
operations. In particular, it is an explanation of how it is done in
those two languages.
Why would you object to my leveraging what I know in other languages
to learn Perl? I have routinely used a student's or colleague's
knowledge of one programming language to more quickly learn another
they needed but had not yet started to study. In my experience, using
similarities and differences between languages a student knows and the
one(s) he is trying to learn greatly accelerates his learning (but it
depends on the instructor or mentor knowing both very well).
Ted
| 
XML Sitemap