Front page | perl.perl5.porters |
Postings from January 2012
On Thu, Jan 26, 2012 at 11:04, Abigail <abigail@abigail.be> wrote:
> On Wed, Jan 25, 2012 at 11:46:15PM +0100, Ęvar Arnfjörš Bjarmason wrote:
>> Also while I agree that it should be a lexical rather than a global
>> that also means with Perl's dynamicness that it has to be a pad lookup
>> instead of looking at a global flag every time we stringify undef.
>>
>> I'd much prefer a simpler runtime than one that has to bend over
>> backwards to accommodate obscure features like the proposed patch.
>>
>> And reading over the test suite just hurts my brain, ties are bad
>> enough, but now I can't even rely on declarations like:
>>
>> my $x;
>> $x == 5;
>>
>> Doing what I think they mean without searching for
>> ${^UNDEF_STRINGIFIES_AS} in the file, or possibly as a global, ew!
>
>
> *shrug*.
>
> I don't buy this counter argument. Sure, it's theoretical possible, but
> how often do you think this will happen? Besides, the "5" itself may be
> overloaded, with or without the patch, you'd have to search for
> "overload::constant". But in practice, although the possibility of overloaded
> constants exists, I never feel the need to scan the source for overloading
> constants lest I cannot rely on checks like '$x == 5'.
How about this one: It's solving the problem at completely the wrong
level of abstraction.
If the entire point of this is to turn this:
my $bar;
print "foo $bar";
Into:
"foo <undef>";
It makes much more sense to do that by doing something like:
my $bar;
print custom_stringification_op_with_hook_into_the_parser("foo $bar");
Or:
my $bar;
print i_know_how_to_inspect_the_caller's_lexical_pad('foo $bar');
Both of which could print "foo <undef>". Supporting a debugging
feature like this by hooking into the stringification of *everything*
is like hunting deer with nuclear weapons.
Thread Previous
|
Thread Next