Front page | perl.perl5.porters |
Postings from January 2012
On 22 January 2012 21:57, Father Chrysostomos <perlbug-followup@perl.org> wrote: > # New Ticket Created by Father Chrysostomos > # Please include the string: [perl #108780] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=108780 > > > > According to the overload documentation, overload::StrVal returns the string that "" would return in the absence of string overloading. > > But this isn’t actually the case: > > $\ = "\n"; > use overload; > no overloading; > print qr//; # prints (?^:) > print overload::StrVal(qr//); # prints Regexp=REGEXP(0x803e50) > > qr// thingies are not actually using overloading. They used to I think. And I think they should act like they are. > overload::StrVal pretends that they are. I would expect that it does. > The overloading pragma knows they are not. > > Should one of overload::StrVal and overloading.pm change to match the other? This one is tough. The normal stringification behavior of a qr// object is supposed to be the pattern, however one should also IMO be able to get the form returned by overload::StrVal somehow. > Or should the we just document this oddity? > > This discrepancy is unfortunate, as it prevents this type of simplification: > > commit 8f6eeb4da8aeaa8cbb3b291181bdac4515d92e2d > Author: Father Chrysostomos <sprout@cpan.org> > Date: Wed Jan 18 13:03:32 2012 -0800 > > In overload::AddrRef, use ‘no overloading’ > > This speeds this up by about 13 times. Yes that is unfortunate. I don't know if there is tricky way to make this happen. One might almost argue this a regression from when qr// objects where turned into first class SV types. Wonder what Nicholas says. Cheers, yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next