Nathan Wiger <[EMAIL PROTECTED]> writes:
> undef has a very well-defined (ha!) Perl meaning: that something is
> undefined. null has a very well-defined RDBMS meaning: that something is
> unknown. Perl allows you to add and concatenate stuff to undef, because
> that value can be coerced into 0 and "" without harm.
This isn't a major loss with a pragma in effect since -w clean code
already can't do this. I don't see the harm in changing this to null
semantics when you ask for that.
About the only piece of code of mine that this would affect are places
where I use ++ on an undef value, and that's not a bad thing to avoid as a
matter of style anyway (usually I'm just setting a flag and = 1 would work
just as well; either that, or it's easy enough to explicitly initialize
the counter to 0).
> Using the proposed tristate pragma does not strike me as any better - in
> fact, worse - than adding null() because you are now changing the
> meaning of fundamental Perl operations.
But that's exactly what you want to do.
> You're *still* introducing "yet another state of null", but to do so
> you're conflating undef and null, which are themselves different
> concepts.
I strongly disagree. You're not changing the data types at all; you're
changing what Perl's operatings (logical, addition, concatenation, etc.)
do with undefined values. Instead of coercing to 0, you coerce to an
undefined value.
I really like this. I could see lots of cases other than just databases
where this would be a useful thing to do with undef. It becomes
considerably less useful if you introduce a new keyword, since then it
requires rewriting code. Those undef semantics could be useful for error
checking in existing code.
> For example, assuming this code:
> $name = undef;
> print "Hello world!" if ($name eq undef);
So don't do that. Use C<defined $name> if you want to ask that question.
Most code that I've seen already does that; checking equality with undef
is an odd way of writing it. *If* you want to use the pragma, just always
write that as C<defined $name>.
> The same operation would print "Hello world!" in one circumstance, but
> nothing under the tristate pragma. This is just as dangerous as having a
> pragma like so:
> use 'zeroistrue';
> $num = 0;
> print "Got data" if ( ! $num );
> Where the above would print out "Got data" normally, but not under the
> pragma.
I strongly disagree here too. 0 as false and 1 as true is an assumption
made in multiple other programming languages, something used by the
majority of Perl scripts that I write, and something that's very
intuitive. undef semantics, on the other hand, are specific to Perl and
the default is chosen to be friendly to quick and dirty scripts. Changing
those semantics to propagate undef makes perfect sense to me.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
