[30240] in Perl-Users-Digest
Perl-Users Digest, Issue: 1483 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Apr 25 17:11:46 2008
Date: Fri, 25 Apr 2008 14:11:35 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 25 Apr 2008 Volume: 11 Number: 1483
Today's topics:
Re: use of DBI; I am getting multiple error messages mi <tzz@lifelogs.com>
Re: use of DBI; I am getting multiple error messages mi <joost@zeekat.nl>
Re: use of DBI; I am getting multiple error messages mi <joost@zeekat.nl>
re: use of DBI; I am getting multiple error messages mi <1usa@llenroc.ude.invalid>
Re: use of DBI; I am getting multiple error messages mi <1usa@llenroc.ude.invalid>
Re: use of DBI; I am getting multiple error messages mi <mgjv@tradingpost.com.au>
Re: use of DBI; I am getting multiple error messages mi <jurgenex@hotmail.com>
Re: use of DBI; I am getting multiple error messages mi <abigail@abigail.be>
Re: use of DBI; I am getting multiple error messages mi <joost@zeekat.nl>
Re: use of DBI; I am getting multiple error messages mi <abigail@abigail.be>
Re: use of DBI; I am getting multiple error messages mi <joost@zeekat.nl>
Re: use of DBI; I am getting multiple error messages mi <abigail@abigail.be>
Re: use of DBI; I am getting multiple error messages mi <tzz@lifelogs.com>
Re: use of DBI; I am getting multiple error messages mi xhoster@gmail.com
Re: use of DBI; I am getting multiple error messages mi <1usa@llenroc.ude.invalid>
Re: use of DBI; I am getting multiple error messages mi <tzz@lifelogs.com>
Re: use of DBI; I am getting multiple error messages mi <tzz@lifelogs.com>
Re: use of DBI; I am getting multiple error messages mi (Ben Bullock)
Re: use of DBI; I am getting multiple error messages mi <tzz@lifelogs.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 23 Apr 2008 16:23:29 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: use of DBI; I am getting multiple error messages mixed in with the correct output.
Message-Id: <86tzhs2rla.fsf@lifelogs.com>
On Wed, 23 Apr 2008 13:40:58 -0700 (PDT) smallpond <smallpond@juno.com> wrote:
s> Each call to fetchrow_arrayref gets a new row, but you
s> only check numFields once. So your rows don't all have
s> the same number of fields.
That SELECT SQL query will not return a variable number of fields.
The problem is that there are NULL values, which are undefined in the
DBI translation. So this
printf("%s%s", $i ? "," : "", $$ref[$i]);
should be (for example)
printf("%s%s", $i ? "," : "", $$ref[$i]||'NULL');
Of course, the code could be greatly improved with a join() call and in
many other places, but I don't feel like rewriting the whole thing.
Ted
------------------------------
Date: Thu, 24 Apr 2008 00:31:57 +0200
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: use of DBI; I am getting multiple error messages mixed in with the correct output.
Message-Id: <874p9snqxu.fsf@zeekat.nl>
Ted <r.ted.byers@rogers.com> writes:
[ on the conversion of NULL fields to <undefined> ]
> This would be a useful tidbit to add to the documentation. I 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.
> I do not, for example, have to go through any such extra hoops when
> using JDBC with JSF. If a particular record set contains nulls in one
> or more columns in one or more records, JSF automagically displays it
> as an empty string; something I have modified on occassion to display
> the string "N/A".
Perl does the same thing, but it will issue a warning if you have
warnings enabled (warnings are output to STDERR, so if you're capturing
STDOUT only it shouldn't be a problem - I haven't read all of the
thread). *If* you don't want to deal with that, either don't "use
warnings" and don't use the -w flag, or do use them in general but
disable warnings in the offending code block.
In my opinon warnings are very useful and should be enabled as much as
possible, but in the particular cases/constructs where it they cause
problems, you shouldn't be afraid to disable them (using "no
warnings"). See perldoc warnings and perldoc no.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Thu, 24 Apr 2008 00:34:18 +0200
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: use of DBI; I am getting multiple error messages mixed in with the correct output.
Message-Id: <87zlrkmc9h.fsf@zeekat.nl>
Joost Diepenmaat <joost@zeekat.nl> writes:
> In my opinon warnings are very useful and should be enabled as much as
> possible, but in the particular cases/constructs where it they cause
^^ disregard that
> problems, you shouldn't be afraid to disable them (using "no
> warnings"). See perldoc warnings and perldoc no.
^^ oops, there that
doens't exist. See
perldoc -f use
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Wed, 23 Apr 2008 23:38:49 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: re: use of DBI; I am getting multiple error messages mixed in with the correct output.
Message-Id: <Xns9A89C7DACAB30asu1cornelledu@127.0.0.1>
Ted <r.ted.byers@rogers.com> wrote in news:3b842be5-7145-42f6-9f5a-
ad1c3a50ad35@x35g2000hsb.googlegroups.com:
> table is returned. However, The correct output is punctuated about
> every 100 lines by hundreds of error messages: "Use of uninitialized
> value in printf at k:/MerchantData/MSDB.pl line 34." That is the
> printf in the for loop within the while loop. This increases the
> number of lines of output from precisely 529 to more than 1800! That
> is almost three times as much garbage as there is real data.
1. Those are warnings, not errors. The difference matters.
2. By default, warnings go to STDERR.
3. The easiest way to deal with warnings is to avoid the behavior
causing them.
4. After careful consideration, you may also choose to disable specific
types of warnings in specific scopes. Read perldoc perllexwarn.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Wed, 23 Apr 2008 23:43:13 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: use of DBI; I am getting multiple error messages mixed in with the correct output.
Message-Id: <Xns9A89C8997336Easu1cornelledu@127.0.0.1>
Ted <r.ted.byers@rogers.com> wrote in news:8db4922e-cd7e-4345-93cf-
b3516d3cc01a@z72g2000hsb.googlegroups.com:
> But, if I understand your final statement correctly, am I to belief it
> is choking on the fact that some of the fields in some of the rows
> have null values?
There is no choking. perl is telling you that you have attempted to use
an undefined value.
> JDBC). But there is no a priori way to tell which columns in which
> rows will be null.
Therefore, you should check values with 'defined' and use suitable
defaults before printing or manipulating them.
> I have found it easy t work around nulls in SQL
> and JDBC and C++, so what it the Perl counterpart to the routine
> idioms I use in these other languages?
I don't know what idioms you are talking about.
In Perl, you check if a value is defined using
perldoc -f defined
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Thu, 24 Apr 2008 13:10:02 +1000
From: Martien Verbruggen <mgjv@tradingpost.com.au>
Subject: Re: use of DBI; I am getting multiple error messages mixed in with the correct output.
Message-Id: <slrng0vuga.fmo.mgjv@martien.heliotrope.home>
On Wed, 23 Apr 2008 18:24:31 -0700 (PDT),
Ted <r.ted.byers@rogers.com> wrote:
> On Apr 23, 6:31 pm, Joost Diepenmaat <jo...@zeekat.nl> wrote:
>> Ted <r.ted.by...@rogers.com> writes:
>>
>> [ on the conversion of NULL fields to <undefined> ]
>>
>> > This would be a useful tidbit to add to the documentation. I 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. My understanding of undefined in
> Perl was to relate it to uninitialized values in Java or C++. You
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?
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.
SQL NULL maps, IMO, very well to Perl undef.
If you still think the DBI is broken, instead of you having the wrong
idea of what undef means, you should probably have this argument with
the DBI developers, who will probably be much better be able to explain
to you why it is not broken.
Martien
--
|
Martien Verbruggen |
| "Mr Kaplan. Paging Mr Kaplan..."
|
------------------------------
Date: Thu, 24 Apr 2008 05:17:24 GMT
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: use of DBI; I am getting multiple error messages mixed in with the correct output.
Message-Id: <be50145oi5rq88ka0u3p0qr6k6g24j1pnn@4ax.com>
Ted <r.ted.byers@rogers.com> wrote:
>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
------------------------------
Date: 24 Apr 2008 11:10:05 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: use of DBI; I am getting multiple error messages mixed in with the correct output.
Message-Id: <slrng10qkd.upq.abigail@alexandra.abigail.be>
_
Ben Bullock (benkasminbullock@gmail.com) wrote on VCCCL September
MCMXCIII in <URL:news:fuplm6$7nl$1@ml.accsnet.ne.jp>:
%% On Wed, 23 Apr 2008 18:24:31 -0700, Ted wrote:
%%
%% > My understanding of undefined in
%% > Perl was to relate it to uninitialized values in Java or C++. You
%% > declare a variable, but then attempt to use it before you define it
%% > (i.e. give it a value).
%%
%% I don't know Java, but uninitialized values in C++ are completely
%% different from undefined values in Perl. An uninitialized C++ variable
%% just contains random garbage, but Perl's undefined values are something
%% meaningful, i.e. you can test whether a variable is undefined or not.
%%
%% > The idea of NULL in SQL is very different. It
%% > IS a valid value that can be given to variables or to fields in specific
%% > rows, where the table definition allows it.
%%
%% So it sounds just like an undefined value in Perl.
Up to there, yes. But it behaves quite differently. Undefined values in
Perl become 0 or the empty string if the context requires so. But not
so with SQL NULLs (see below).
%% What value would you
%% give a Perl scalar to represent an SQL null, if not the undefined value?
%% A string saying "NULL"? A special "NULL" object? What would their
%% advantage be over just Perl's regular undefined value?
Well, there would be some advantages of using a special NULL object
instead of 'undef'. Because an SQL NULL behaves differently from an
undef. For instance, when doing arithmetic, an 'undef' behaves like
a 0, while an SQL NULL behaves like a NaN:
3 + NULL == NULL (SQL)
3 + undef == 3 (Perl)
3 + NaN == NaN (Perl)
Unfortunally, there's no NaN equivalent for strings, and when you get
something out of a database, DBI cannot know whether it's going to be
used as a string, or as a number.
%% > NULLs in SQL carry a very
%% > specific meaning, and require very specific behaviours when handling
%% > them. To translate this into a language like Java or C+ +, I would
%% > write a class that provides for the same meaning and behaviours that
%% > would be familiar to a SQL programmer. Had I known that the DBI was
%% > broken in terms of translating database nulls into <undefined>
%%
%% I really do not think that it's broken.
I'd say, mapping SQL NULLs to undef was a choice. It's often convenient,
but can be surprising if you're used to SQL NULLs and the wrong choice
if you need the same behaviour. Another choice would have been NaN, but
that makes string handling more cumbersome.
%% > I'd have
%% > considered developeing an extension to DBI; one that included a NULL
%% > class that would serve the needs of database programmers.
%%
%% What would it do, exactly?
If I were to implement is, an object of such a class would have overloaded
all operations and return another NULL object for all operations, except
when comparing it with NULL (in which case it would return a true value).
Abigail
--
$_ = "\nrekcaH lreP rehtona tsuJ"; my $chop; $chop = sub {print chop; $chop};
$chop -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> ()
-> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> () -> ()
------------------------------
Date: Thu, 24 Apr 2008 14:14:02 +0200
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: use of DBI; I am getting multiple error messages mixed in with the correct output.
Message-Id: <87d4offo1h.fsf@zeekat.nl>
Ted <r.ted.byers@rogers.com> writes:
> 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/
------------------------------
Date: 24 Apr 2008 13:41:30 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: use of DBI; I am getting multiple error messages mixed in with the correct output.
Message-Id: <slrng113g9.66h.abigail@alexandra.abigail.be>
_
Ben Bullock (benkasminbullock@gmail.com) wrote on VCCCL September
MCMXCIII in <URL:news:fupu4i$8t8$1@ml.accsnet.ne.jp>:
`` On Thu, 24 Apr 2008 11:10:05 +0000, Abigail wrote:
``
`` > Well, there would be some advantages of using a special NULL object
`` > instead of 'undef'. Because an SQL NULL behaves differently from an
`` > undef. For instance, when doing arithmetic, an 'undef' behaves like a 0,
`` > while an SQL NULL behaves like a NaN:
`` >
`` > 3 + NULL == NULL (SQL)
``
`` I'm guessing that when we subsequently try to use this value somewhere,
`` then we have an unhappy consequence.
Depends on how you use it.
But that already happens in Perl as well, for example, @{undef} also leads
to unhappy consequences (if you've turned on strict).
`` > 3 + undef == 3 (Perl)
``
`` This produces the kind of error message the original poster's query was
`` about.
``
`` > 3 + NaN == NaN (Perl)
``
`` OK, but I can't see the advantages of translating the SQL NULL into a
`` special Perl object unless we also translate all the SQL strings into
`` special SQL string objects which behave just like SQL strings, and SQL
`` number objects which behave just like SQL numbers, etc. etc. I don't see
`` the value in it. If he wants to get SQL behaviour then why not just stick
`` with manipulating the data inside the database via SQL statements in DBI,
`` rather than pulling the values into Perl variables and then imposing a
`` kind of "fake SQL" behaviour on the Perl variables.
Ah well, if Perl+CPAN only had things you could see the advantage of...
I won't object if the OP writes an extension to the DBI that used special
NULL objects.
Abigail
--
perl -Mstrict='}); print "Just another Perl Hacker"; ({' -le1
------------------------------
Date: Thu, 24 Apr 2008 15:45:07 +0200
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: use of DBI; I am getting multiple error messages mixed in with the correct output.
Message-Id: <877iene598.fsf@zeekat.nl>
Ted <r.ted.byers@rogers.com> writes:
> 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.
I think that undef is a good choice for NULL if you want to map SQL
values to "native" perl values. undef is /conceptually/ the closest perl
has to SQL NULL.
If on the other hand, you want values that /behave/ like their SQL
counterparts, that would mean that most values would behave differently
from the built-in perl types. And that would make it much more
cumbersome to use data from the database in perl code that doesn't
expect that behaviour (which would be almost all reusable code).
It would probably not be too much work to wrap DBI to return a special
NULL object instead of undef, for example, but I think the current
mapping makes the most sense for a relatively low-level interface like
DBI.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: 24 Apr 2008 13:55:59 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: use of DBI; I am getting multiple error messages mixed in with the correct output.
Message-Id: <slrng114bf.66h.abigail@alexandra.abigail.be>
_
Joost Diepenmaat (joost@zeekat.nl) wrote on VCCCL September MCMXCIII in
<URL:news:877iene598.fsf@zeekat.nl>:
^^ Ted <r.ted.byers@rogers.com> writes:
^^
^^ > 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.
^^
^^ I think that undef is a good choice for NULL if you want to map SQL
^^ values to "native" perl values. undef is /conceptually/ the closest perl
^^ has to SQL NULL.
No, 'undef' is a compromise. When using numbers, and numerical operators,
NaN is much closer to an SQL NULL than undef is. However, Perl has only
typed values, and mixes and matches strings and numbers without explicite
casting. And there isn't a string alternative for NaN.
^^ If on the other hand, you want values that /behave/ like their SQL
^^ counterparts, that would mean that most values would behave differently
^^ from the built-in perl types. And that would make it much more
^^ cumbersome to use data from the database in perl code that doesn't
^^ expect that behaviour (which would be almost all reusable code).
Really? I claim that good code, that is, code that uses warnings, will
have to deal with 'undef's explicite anyway, because most operators will
issue a warning if one or more of their arguments is undefined anyway.
^^ It would probably not be too much work to wrap DBI to return a special
^^ NULL object instead of undef, for example, but I think the current
^^ mapping makes the most sense for a relatively low-level interface like
^^ DBI.
Abigail
--
perl -wle 'eval {die [[qq [Just another Perl Hacker]]]};; print
${${${@}}[$#{@{${@}}}]}[$#{${@{${@}}}[$#{@{${@}}}]}]'
------------------------------
Date: Thu, 24 Apr 2008 09:56:36 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: use of DBI; I am getting multiple error messages mixed in with the correct output.
Message-Id: <861w4v2tej.fsf@lifelogs.com>
On Wed, 23 Apr 2008 14:40:14 -0700 (PDT) Ted <r.ted.byers@rogers.com> wrote:
T> This would be a useful tidbit to add to the documentation. I hadn't
T> expected a mature library like DBI to behave like this. I do not, for
T> example, have to go through any such extra hoops when using JDBC with
T> JSF. If a particular record set contains nulls in one or more columns
T> in one or more records, JSF automagically displays it as an empty
T> string; something I have modified on occassion to display the string
T> "N/A".
I saw your discussion with the others, it covered all the bases. I
agree with Abigail (unsurprisingly), but I also think the current DBI
approach is the best compromise between ideology and pragmatism.
T> You needn't worry about rewriting the whole thing as I'll be doing
T> that anyway as I learn to translate more of what I know from C++,Java
T> and SQL into Perl. But perhaps you could give me a break and make
T> some suggestions as to what improvements you'd recommend and where to
T> look for details in the documentation.
Use an options hash with Getopt::Long.
Instead of $$var[$i], use $var->[$i].
Learn about join, map, and grep.
Have fun. Always look for a shorter, smarter way to do something.
T> And one thing I haven't found yet, which I am sure must be there
T> somewhere, is how to set up a bulk insert. Can you point me in the
T> right direction to see how to do that using DBI?
Bulk inserts are annoyingly hard to do in a generic way. You've got to
do it with the database's particular facility. Postgres, for example,
has a statement that will import a file; Sybase has an entirely external
utility for this task and no internal functionality.
Ted
------------------------------
Date: 24 Apr 2008 14:58:55 GMT
From: xhoster@gmail.com
Subject: Re: use of DBI; I am getting multiple error messages mixed in with the correct output.
Message-Id: <20080424105856.710$ig@newsreader.com>
Abigail <abigail@abigail.be> wrote:
> _
>
> %% > I'd have
> %% > considered developeing an extension to DBI; one that included a NULL
> %% > class that would serve the needs of database programmers.
> %%
> %% What would it do, exactly?
>
> If I were to implement is, an object of such a class would have
> overloaded all operations and return another NULL object for all
> operations, except when comparing it with NULL (in which case it would
> return a true value).
But in SQL, comparing NULL with NULL gives NULL, not true. At least with
ordinary comparison operators. Also, for the "and" and "or" operators,
sometimes they give non-NULLs.
NULL and false = false
NULL and true = NULL
NULL or false = NULL
NULL or true = true
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Thu, 24 Apr 2008 17:01:12 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: use of DBI; I am getting multiple error messages mixed in with the correct output.
Message-Id: <Xns9A8A84711EAFFasu1cornelledu@127.0.0.1>
Ted <r.ted.byers@rogers.com> wrote in
news:064ae74c-23e2-4034-828d-4c22ee292381@l42g2000hsc.googlegroups.com:
> On Apr 24, 10:56 am, Ted Zlatanov <t...@lifelogs.com> wrote:
...
>> I saw your discussion with the others, it covered all the bases. I
>> agree with Abigail (unsurprisingly), but I also think the current DBI
>> approach is the best compromise between ideology and pragmatism.
>>
> She is a gem, isn't she?!!
s/[Ss]he/he/g
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Thu, 24 Apr 2008 13:23:03 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: use of DBI; I am getting multiple error messages mixed in with the correct output.
Message-Id: <868wz315a0.fsf@lifelogs.com>
On Thu, 24 Apr 2008 09:31:05 -0700 (PDT) Ted <r.ted.byers@rogers.com> wrote:
T> She is a gem, isn't she?!!
Abigail's gender should be in the FAQ :)
T> I learned plenty about the perl side of things from her posts. And I
T> found Ben's last example, using undef to ignore certain values,
T> interesting. But his first example remains problematic. Between the
T> two, and others, I can see some logic in choosing undef as a pel
T> primitive to represent SQL NULLS, but it seems to me that with the
T> support now available for object oriented programming in perl, it
T> would have been relatively trivial to provide a new class to more
T> closely represent the SQL idea of a null. When I did it in Java, all
T> I had to do was add a private data member of type boolean, and then
T> check this data member in those member functions where it is relevant
T> that override functions provided in the relevant base classes.
Objects in Perl are not always the right solution. undef takes a lot
less memory than a blessed object, for example, and it's faster. Also,
it's annoying if you just want to deal with values (compare with Java's
painfully horrible Integer vs. int hack, repeated for a bunch of
primitives).
Like I said, it's a compromise. By definition some people won't like
it. I think it's the right thing in the context of Perl, and obviously
most people like the DBI as it is or it would have been changed long
ago. I would address it by adding a DBI function is_null() that can be
attached to a row somehow, so you can say
while (my $row = ...)
{
if (is_null($row, $column)) { ... } # doesn't matter how is_null is invoked
}
T> BTW: having read the thread, you see where Ben and I seem to be
T> butting heads. Can you point me to places in the Perl reference that
T> substantiate his perspective on the points where we disagree, and
T> which provide a fuller explanation of his point of view?
I'm not sure what exactly you're asking. I don't think Ben said
anything wrong, and I don't think (but could be wrong) there's a
specific reference document on the topic you were discussing. There's
bits and pieces all over. I think Ben would have pointed you to the
right document already if it was in one place.
Ted
------------------------------
Date: Thu, 24 Apr 2008 16:36:58 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: use of DBI; I am getting multiple error messages mixed in with the correct output.
Message-Id: <86ej8vylxh.fsf@lifelogs.com>
On Thu, 24 Apr 2008 12:57:09 -0700 (PDT) Ted <r.ted.byers@rogers.com> wrote:
T> He objected most strenuously to the notion that [undef] refers to an
T> uninitialized variable, even though his first example clearly used an
T> uninitialized variable to illustrate the idea of undef. The second
T> is that he maintains that the empty string is the idea of a defined
T> null, and that that is something Wall et al. were referring to.
I'll illustrate with code.
use Data::Dumper;
my $null; # uninitialized variable
my $one = 1;
my $formerly_defined = 1;
undef $formerly_defined;
foreach my $check (1, 0, '0', '0.00', '', $null, $one, undef, $formerly_defined)
{
print $check ? 'true' : 'false';
print ', ';
print defined $check ? 'defined' : 'not defined';
print ', ';
print 'value = ', Dumper($check);
}
This produces:
true, defined, value = $VAR1 = 1;
false, defined, value = $VAR1 = 0;
false, defined, value = $VAR1 = '0';
true, defined, value = $VAR1 = '0.00';
false, defined, value = $VAR1 = '';
false, not defined, value = $VAR1 = undef;
true, defined, value = $VAR1 = 1;
false, not defined, value = $VAR1 = undef;
false, not defined, value = $VAR1 = undef;
See how $formerly_defined has been initialized to 1, then undefined.
It has been set twice, the second time to the undefined value. This is,
I think, what Ben meant.
I don't know if this is in a single place in the docs, but see `perldoc
perltrap' `perldoc perlsyn' `perldoc perlnumber' among others.
T> I don't have a problem regarding the empty string as a defined null
T> string, if that's the way things are defined in Perl
Basically the rules above are what they are, and are essential to Perl's
DWIM. The DBI, to get back to the point of the thread, does the best it
can with what's available. You can't get an undef back unless the value
is NULL, so really your problem is in the further treatment of the undef
vs. how SQL would treat the NULL. That Perl behavior is not likely to
change in the future, so either use the undef and know the effects, or
wrap it in your own classes that do the right thing for your needs.
T> That you saw nothing wrong in what Ben wrote would suggest to me that
T> he is drawing on a common belief in the perl programming community,
T> and it seems to me that there remain things here to be explained in
T> more detail.
I don't think it's productive to direct the argument at Ben. Say what's
still unclear and we'll clear it up. Code always is more precise than
words, so ask about code if possible.
Ted
------------------------------
Date: Fri, 25 Apr 2008 02:05:20 +0000 (UTC)
From: benkasminbullock@gmail.com (Ben Bullock)
Subject: Re: use of DBI; I am getting multiple error messages mixed in with the correct output.
Message-Id: <fure90$kik$1@ml.accsnet.ne.jp>
Ted Zlatanov <tzz@lifelogs.com> wrote:
> See how $formerly_defined has been initialized to 1, then undefined.
> It has been set twice, the second time to the undefined value. This is,
> I think, what Ben meant.
It's partly what I meant. It's incorrect to think of Perl's
"undefined" value as being equivalent to an uninitialized variable in
many other ways. For example
return;
in a scalar context gives an "undefined" result, but the "undefined"
here has absolutely nothing to do with something not being
initialized.
"Undefined" in Perl is a kind of flag which tells you something about
a situation, like your subroutine gave up halfway through, or your
hash or array variable doesn't exist, or maybe you have a NULL in your
SQL table. Undefined doesn't behave exactly like a pointer to zero in
C++, an uninitialized variable in C++, or a zero-length (i.e. '\0'
terminated) array of characters in C++. I don't see the point in
trying to make a more and more tortured analogy between Perl's
undefined value and concepts from another language. To understand what
"undef" is in Perl you need to look at what Perl does with it.
------------------------------
Date: Fri, 25 Apr 2008 09:29:05 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: use of DBI; I am getting multiple error messages mixed in with the correct output.
Message-Id: <86prsexb2m.fsf@lifelogs.com>
On Thu, 24 Apr 2008 19:39:20 -0700 (PDT) Ted <r.ted.byers@rogers.com> wrote:
T> Is there any reason to regard the code you have provided as referring
T> to anything other than uninitialized variables and how to detect and
T> handle them?
As Ben mentioned, return() from a subroutine without a value does not
involve variables. Just think of defined() as Perl's way of checking if
a value is useful or not.
I can't think of all the other cases. I don't see the point, either.
We're just going back and forth over the same ideas, and we've covered
everything you will need to know about defined() in Perl for the time
being. If you need to dig deeper, you should look at the Perl source
code to understand the nuances of how defined() works.
Ted
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 1483
***************************************
