use of DBI; I am getting multiple error messages mixed in with the correct output.
in [Perl]
|
Prev: FAQ 1.15 Where can I get a list of Larry Wall witticisms?
Next: use of DBI; I am getting multiple error messages mixed in with the correct output.
From: RedGrittyBrick on 24 Apr 2008 12:48 Ted wrote: > On Apr 24, 10:56 am, Ted Zlatanov <t...(a)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?!! > He (Abigail) may well be a gem. -- RGB
From: Dr.Ruud on 24 Apr 2008 12:50 Ted schreef: > 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. Troll alert. -- Affijn, Ruud "Gewoon is een tijger."
From: Ted on 24 Apr 2008 15:57 On Apr 24, 2:23 pm, Ted Zlatanov <t...(a)lifelogs.com> wrote: > On Thu, 24 Apr 2008 09:31:05 -0700 (PDT) Ted <r.ted.by...(a)rogers.com> wrote: > > T> She is a gem, isn't she?!! > > Abigail's gender should be in the FAQ :) > Must be a cultural thing. I have always seen the name Abigail used for women. My apologies to Abigail! > 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). > ;-) If I were inclined to obstructionist, I could waste a lot of time criticizing each of the languages I use. There are lots of things in Java I'd love to change if I could, but .... And even Stroustrup, the primary inventor of C++, has described a number of things he'd have done differently. But then nothing is perfect, and it is important to understand the rationale behind the compromises that have been made in each. > 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 > > } > Nice idea. But the kind of object I had in mind is about as stripped down as the smart pointer in C++, or perhaps some of the format classes in Java. > 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. > There seem to be two key disagreements. In the book I've relied on for Perl Programming, by Wall et al., the description of undef they give seems to be to be a near perfect definition of what is true of an uninitialized variable in, e.g., C++ or Java. His treatment of it, though, implies that what I read in Wall et al.'s book is either wrong or misleading. He objected most strenuously to the notion that it refers to an uninitialized variable, even though his first example clearly used an uninitialized variable to illustrate the idea of undef. The second is that he maintains that the empty string is the idea of a defined null, and that that is something Wall et al. were referring to. But I have found nothing in that book that suggests that in perl the empty string is the same thing as a defined null string. Wall et al. don't say what they mean by a defined null string, but then they say nothing that implies that they use that term to mean an empty string either. I have five books on Perl, include that by Wall et al., along with the documentation that came with ActiveState's build of version 5.8.8, and none mentions anything would either supports or explains his position on either of these two issues, at least as far as I've been able to progress through them. I don't have a problem regarding the empty string as a defined null string, if that's the way things are defined in Perl, but I have not seen such a definition except in what Ben wrote. For that, I was just hoping to be pointed to a page in the perl reference that states this explicitly. Either way, I can write code that means what I intend. Had Ben just pointed me to the right page in the perl reference that gives, and explains the rational behind, this definition, I would have thanked him and said nothing more on the matter. On the matter of undefined, though. Wall et al. say that an undefined variable is one that does not presently hold a valid string, numeric or reference value. The only way I see that happening is if the variable is not initialized. Ben's first example, in fact, then uses an uninitialized variable to illustrate the idea of undefined. And then I learn in this thread, that perl silently, implicitly does to undefined variables what I do explicitly in my C++ and Java code when a valid value in not yet known or available at the point of the declaration. And Ben maintains that this is not focussed on uninitialized variables. Do you see the contradiction between Wall et al.'s description of undefined variables and their behaviour in Ben's first example on the one hand and Ben's insistence that they are not uninitialized variables on the other? Or at least why someone coming to perl programming from extensive experience with languages like C++ and Java would see this as a contradiction? Surely this is something that needs explanation, all the better if reference, and comparison, is made to how uninitialized variables are handled in other programming languages for the benefit of those of us trying to learn Perl who have an extnesive hisotyr with other programming languages. That you saw nothing wrong in what Ben wrote would suggest to me that he is drawing on a common belief in the perl programming community, and it seems to me that there remain things here to be explained in more detail. Thanks Ted
From: Ted on 24 Apr 2008 22:39
On Apr 24, 5:36 pm, Ted Zlatanov <t...(a)lifelogs.com> wrote: > On Thu, 24 Apr 2008 12:57:09 -0700 (PDT) Ted <r.ted.by...(a)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. > Thanks Ted. This is very helpful. > 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; > You know, this is precisely how I have conceived of undef working since I first read Wall et al. It is good to know I haven't grossly misunderstood it all this time. > 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. > Yes, I noticed this, and this is exactly analogous to setting java variables to null when you're done with them, or setting C++ pointers to null (after invokving operator delete or function free on them as appropriate before doing so). If this is the basis for Ben's objection to my stating that undef is, fundamentally, a question of initialization of variables and how they're to be handled, then at best he overstated his position. To understand why I say that being able to undef a variable does not weaken the relation to uninitialized variables, it may be useful to use a pair of examples from java and C++. In java, when you're done with a variable, you can let it disappear when it goes out of scope or you can set the variable to null. A java null is never a valid value for a string, number, or instance of any class. But it is easy to test for, and it means that the variable is not presently initialized to a valid value. Similarly, a C++ pointer is, at base, a memory address. The value 0 is never a valid memory address, but again it is easy to set all the bits of a pointer variable to 0. And this too is easy to test for, which is why we do it. What it means is that the pointer in question is not presently initialized to a valid memory address. Is there any reason to regard the code you have provided as referring to anything other than uninitialized variables and how to detect and handle them? > I don't know if this is in a single place in the docs, but see `perldoc > perltrap' `perldoc perlsyn' `perldoc perlnumber' among others. > Thank you. > 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. > I am not looking to change perl, but rather understand it. Certainly, I can work with it as it is. > 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. > ;-) That, my friend, depends on the respective skills of the coder and the writer. I'll restrict my question to that one I embedded in the text above. Referring to the example you have provided, is there any good reason to regard any of it as referring to any idea other than that of variables that have not been initialized to valid string, numeric, or reference values? Thank you. Ted |