Russ Allbery wrote:
use 'strict' is probably the difference between our code... I tend not to use
it, because I wrote a bunch of code that didn't, initially, before I heard of
it (maybe before it existed? I started with Perl 4.something), and haven't
gotten it all converted so that it can be used together with strict. A
project that hasn't yet gotten high enough on my priority list.
> > Going back to your first remark about seeing confusion either way, maybe
> > explaining the types of confusion that you see with a separate null and
> > undef vs the types of confusion that you see with a tristate pragma
> > would help me to grasp that logic.
>
> The main thing I'm worried about with undef plus null is that undef is
> already very hard to explain and having an additional parallel concept
> that behaves slightly differently and that can easily be confused with
> undef is worrisome.
That's an interesting observation. To me, the concept of undef could be
explained in a paragraph. But I've been working with SQL & NULL for 15 years
before I heard of Perl and its undef.... so I had no problem with the concept.
I guess if undef is perceived as hard to understand or explain, then SQL NULL
would be perceived as hard to understand and explain.
To me, SQL NULL is somewhat complex, but understandable, and undef is totally
trivial.
> The advantage of explaining a tristate pragma is that
> with normal undef semantics, most times undef shows up in an arithmetic or
> logical operation other than a simple test of true or false, it's
> symptomatic of poorly-constructed code; increments are about the only
> exception. So the area that tristate logic changes is not something that
> we recommend that people use under normal circumstances.
I can see that. Following that logic down the path of my preferred
implementation, though...
It seems to me that if 99% of the perl operators were simply modified such
that SQL NULL in produced SQL NULL out (which is the net effect of most of the
changes to most of the operators, to achieve the desired semantics), that 99%
or more of the time, a programmer that wants to ignore NULL could quite easily
do so... if they aren't introduced in the input, they won't come out the
output, even if the operators are ready, willing, and able to deal with them.
Which is why I can't see why people get so upset about the idea. undef gets
introduced into their data if they forget to initialize something, and because
some perl operations return it as a failure indication. But SQL NULL would
only get introduced into their data if they explicitly do so, or use something
like a ported DBI. And if they use a ported DBI (ported to use NULL rather
than undef, that is), then they probably speak SQL, and SQL NULL would not be
a new concept.
And if we wanted to make it explicitly 100% ignorable, we could have a pragma
to "enable or disable NULL", which would make it impossible to introduce NULL
into the data (make the null keyword a compile error). But I still think that
when it is turned on, it should be a separate concept.
> > And if/when my database needs require the use of multiple different NULL
> > values (currently they are not there, multiple NULL values do get talked
> > about by relational theorists, and there is some move to put them into
> > the SQL standard, but it appears they haven't yet appeared in one) I see
> > having multiple "special non-values" (as someone else called them) much
> > simpler to extend to the concept of multiple NULL values than the pragma
> > approach.
>
> Hm. Yes, that's a good point. (At that point, something more like
> Quantum::Superpositions may be more what you want.)
Is it? As far as I could read, Quantum::Superpositions defines null as the
empty set. There was no provision for multiple absence concepts. Perhaps
that could be added though.
And if Damien Neil is correct, and if Perl overloading is powerful enough, it
may be possible to overload all the operators to deal with a NULL module,
which could have 29 different instantiated sub-object types? No time until
next week, maybe, to pursue that path further... I've been reluctant to dive
that direction into Perl, until I got my code "strict-ized", but seems like
I'll probably invert that priority.
--
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
