|
Posted by Ted on April 24, 2008, 11:46 am
Please log in for more thread options
On Apr 24, 10:10=A0am, benkasminbull...@gmail.com (Ben Bullock) wrote:
> >> 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.
>
> Excuse me, this should say '$b is a "defined null string"' not "real".
>
OK. Where does this definition of a defined null string come from?
Wall et al. say nothing about it, either in their chapter two, where
they talk about types and other basic matters, or on page 155 where
they talk about undef.
> > 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).
>
> But I'm not talking about C++ or Java or SQL. I'm talking about
> Perl. This is a perl newsgroup. "" is what the book you're referring
> to means by a "defined null string", as opposed to an undefined value.
>
Then why are you arguing in this thread.
The DBI is all about mapping SQL concepts to Perl concepts. Surely
this newsgroup is more logical as a place to discuss that than any
other. I'd assume that it was developed by perl programmers to meet
the need to be able to interact with databases.
And where exactly are you getting the idea that the empty string is a
defined null string. Wall et al. certainly make no reference to such
an idea whether where they talk about types in chapter 2 or where they
talk about undefined on page 155. It is, in fact, a bit of a
frustration that they reference the defined null string without
defining it. But I don't criticise them since there is no such thing
as a perfect product, and therefore any product can be improved.
> > But that is exactly what Wall et al. said about undefined. =A0I 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. =A0The empty string is a valid string in all of the
> > languages I use, and it means something quite different from a SQL
> > null.
>
> We're not talking about the empty string any more, the above is
> talking about an undefined value. As I pointed out in the two scripts,
> $b=3D"" and $b=3Dundef are two totally different things.
>
Agreed. But the empty string is not a defined null, unless that
definition is provided somewhere in the Perl documentation. $b in
$b=3D"" is an empty string, neither null nor undefined. Apart from what
you have written here, I have seen nothing written about perl that
equates the empty string to a defined null.
Wall et al. say nothing about an empty string being conceived as being
the same thing as a defined null, either in their second chapter,
where they talk about types and other basic matters, or on page 155
where they talk about undef.
> >> > But ALL of these concepts are very different from the idea of NULL in=
> >> > SQL. =A0For example, The book, from Osborne, "SQL: The complete refer=
ence"
> >> > by James Groff and Paul Weinberg, described it as referring to data t=
hat
> >> > 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. =A0Where they wrong, or
> > merely misleading?
>
> Look at this kind of example:
>
> my @arr =3D (undef, 1, 3, undef, 4);
>
> If you then refer to $arr[3] you get the undefined value. So you can
> assign it into a variable. What is more you can do things like
>
> (undef, $x, $y) =3D @z;
>
> to ignore the value of $z[0].
>
This is new to me, and quite interesting. And it shows a behaviour
related to the behaviour of SQL NULLs.
> I don't know how that compares to SQL's NULL in detail, but it seems
> to me that this refers to data that is "missing, unknown or does not
> apply", thus from your statement this "seems to be exactly what the
> undefined value in Perl is, to me", as I said.
>
Read Abigail's posts. I found them priceless, and I thank her for
them, for I learned much from her comparison of SQL NULLs and Perl's
undef, especially what she said bout what happens on the Perl side.
> >> > While NULL in SQL is different from
> >> > numeric or string data, I see nothing in the idea that indicates it i=
s 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.
>
> You keep on and on repeating this but I've already pointed out to you
> that it doesn't mean that. Did you actually try running or even
> reading those scripts I gave?
I repeated it because that is what they wrote, and there seems to be a
gulf between what they wrote and what you're writing. Yes, the
scripts show how Perl behaves in the xample context, but there is a
problem with your example because there is no substantiation of your
claim that the empty string is the same thing as a defined null
string. I do not have a problem with such a definition, but would
like to see it somewhere in the perl documents. Is it given there?
If so, where?
But the notion of a defined null string is really a side issue. It
has become appearent to me from what others have written in this
thread that Perl is doing implicitly, using undef, what I routinely do
explicitly in my C++ and Java code. It also does not address the core
problem that a variable that is not defined is not the same idea as
that represented in an SQL null.
> >> > 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 loo=
ks
> >> 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.
>
> Please don't say "not yet" again, I've already given you counter
> examples for that.
>
And as I pointed out, your examples that used $a and $b are
problematic, and thus don't settle the question. Further, your
counter examples don't address the fact I have not seen your use of
undefined as being equivalent in meaning to SQL's NULLs in other Perl
references. See Abigail's posts for a detailed explanation of the
problems with such an equivalence.
Yes, I did find the information you referred to on the DBI page, but
there was no explanation there for the rationale behind such a choice.
> > Why would you object to my leveraging what I know in other languages
> > to learn Perl?
>
> Since you've replied to my post, I assume you're addressing this
> comment to me, so let me say that I don't remember objecting to
> that.
You did so implicitly by apparently complaining that I wrote too much
about these ideas as they are reflected in C++ and Java.
To quote what you said above: "But I'm not talking about C++ or Java
or SQL. I'm talking about Perl. This is a perl newsgroup." You seem
to be implying that mention of ideas expressed in C++ or Java or SQL
is forbidden in this newsgroup. If that is correct, it makes it
impossible to leverage what one knows of these other languages to
learn more about perl, and in particular that would make understanding
how and why the DBI maps SQL cncepts to Perl concepts.
If I misinterpreted what you meant by such comments, I apologize.
Cheers,
Ted
| 
XML Sitemap