Front page | perl.perl5.porters |
Postings from January 2012
Re: [PATCH] undef stringification
Thread Previous
|
Thread Next
From:
David Golden
Date:
January 25, 2012 07:01
Subject:
Re: [PATCH] undef stringification
Message ID:
CAOeq1c8f2c6+rvaAp0S2N3B3Zy9oWSVpFqh_1bsGVYQiScAP5g@mail.gmail.com
I've been debating internally the various dimensions of this patch.
Generally, I like the concept but not the execution. Here is my
$0.02:
(1) I think it should implemented lexically.
While there are comparable global variables, I think those are a
legacy and we shouldn't be adding more of them. I like the brevity of
"$^U" but not enough to want this done as a global.
(2) I would favor a shortish pragma name to encourage adoption with a
sensible default. E.g.
use undef::stringification; # stringify as 'undef'
use undef::stringification '<undef>'; # stringify as '<undef>'
I think "undef::stringification" is a bit long, but I can't think of a
sensible shorter name right now and that's a bikeshed color issue
anyway.
(3) The length of undef should be the length of the string value that
replaces it
When the lexical is not in effect, undef is undef in string context
and its length should be undef. But when the lexical is in effect,
then undef in string context has a defined value and the length of
that should be the length. I think this is the only logical way to
proceed.
use undef::stringification;
my ($foo, $bar) = ("short", undef);
is( length($foo) + length($bar), length($foo . $bar), 'should be true' );
Yes, it can mess up logic tests like "if (length $bar ) { ... }" but
that effect is limited to the lexical scope of the pragma and so is
merely doing exactly what the programmer asked for.
(4) When the pragma is in effect, stringifying an undef value should not warn
Again, when limited to a lexical scope, I think this is logical. The
whole point is to take intentional action when stringifying undef
values and thus it should not warn.
(5) Numeric and boolean contexts
I think the effect should be limited to stringification only.
use undef::stringification;
my $foo;
my $bar = $foo . " is awesome; # "undef is awesome", no warnings
my $bar = $foo + 0; # $foo is undef and warns
if ( $foo ) { ... } # $foo is undef and conditional clause does not execute
if ( defined $foo ) { ... } # ditto
Specifically, the *variable* containing undef should not change. Only
the value that results when undef is stringified should change from
the empty string to whatever the pragma sets.
(6) Considerations for a more general mechanism for affecting default
stringification/numification
While I don't mean to bottleneck this particular patch and "perfect"
should not be the enemy of "good", I can imagine utility for
lexically changing stringification, numification or even
booleanization (is that a word?) of many core values/objects. I
wonder if a more general mechanism, akin to "overload" would make
sense to consider and would address more consistently some edge case
questions and potential desire for future extension.
E.g. what if someone wants this same feature, but for numeric
contexts, too? Maybe they should work like this:
use stringify 'undef' => '<undef>';
use numify 'undef' => 0;
What if someone wants to hook this with a coderef (for whatever strange reason)?
use stringify 'undef' => sub { $ENV{RELEASE_TESTING} ? die($msg) : "undef" };
What if someone wants to extend this to other core objects?
use stringify 're' => sub { "qr{" . substr($_[0],1,-1) . "}" }; #
with %SIG like recursion protections
I don't say we have to do these things now, but if we think we might
ever be tempted to, then a more general mechanism might be
appropriate.
(7) I could vaguely imagine potential benefit for a global hook of the
type I've described in (6) as well but don't think that's necessary to
consider at this point.
-- David
Thread Previous
|
Thread Next