On Jan 22, 2012, at 2:37 PM, yves orton via RT wrote: > 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. $ perl5.6.2 -le 'use overload; print overload::StrVal qr//' Regexp=SCALAR(0x800264) It seems they have always been weird. Is the overloading pragma new enough to change without breaking things?Thread Previous | Thread Next