Peter Scott wrote:
> At 12:38 PM 9/20/00 -0700, Glenn Linderman wrote:
> >OK, scalar variables. But I see code in the XML modules that check
> >defined (@array)
>
> Then they should be fixed. That doesn't do anything useful right now.
I tried to fix it according to the suggested fix in the warning message, and
it didn't work. I tried another logic transformation that I thought might
work, but it didn't. But the code works as is. I agree something should be
fixed.
> >Interesting. I learn something every day. Today, you helped. Maybe you
> >can help
> >some more... implement me an SQL null, that can coexist with Perl undef,
> >not replacing
> >it.
>
> Show me one real example of where this would help. I have never even
> remotely considered such a thing in my DBI programming; I have some
> convenience modules that translate undef to IS NULL when constructing
> queries, and DBI handily turns NULLs into undefs in results for me. If
> this is not about DBMS interfacing but you want Perl to implement SQL
> expression semantics, why? What possible benefit is there?
So that I can write joins, including expressions involving NULLs retrieved
from the databases, using Perl. Not in SQL join syntax, but in Perl. But
Perl doesn't presently support the NULL concept--using undef and its defined
semantics doesn't produce the same results for expression calculation as using
NULL. As stated in other post, even in DB programming of this sort, I
perceive that having undef mean uninitialized value (distinct from NULL
meaning null value read from DB) would help catch programming errors, just as
it does today without support of NULL.
--
Glenn
=====
Even if you're on the right track,
you'll get run over if you just sit there.
-- Will Rogers
_______________________________________________
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
