On 17 Feb 2018 21:36, "Father Chrysostomos via RT" < perlbug-followup@perl.org> wrote: On Fri, 16 Feb 2018 18:53:47 -0800, demerphq wrote: > > It is unfortunate that so many critical functions and checks in Perl > > require namespace mutations, but that's how things work, and imo not > > touching other namespaces has a *much* lower priority than Carp working > > correctly and not segfaulting. Why cannot we have both? You are being vague Carp incorrectly assumes that the only way you can have an overloaded object is if you have loaded overload.pm. Which means that this segfaults due to stack overflow: perl -MCarp -E 'my $p = "OverloadedInXS"; *{$p."::(("} = sub{}; *{$p.q!::(""!} = sub { Carp::cluck "<My Stringify>" }; sub { Carp::cluck("") }->(bless {}, $p);' See #132828. To fix that without loading overload.pm I would have to more or less extract a nice chunk of the internals of overload.pm into Carp. But I am curious why you feel I need to defend making Carp.pm use a module. I feel the onus should be the other way around, it should be on you, or any others who feel Carp should not load modules to explain why Carp is such a special flower. We have no less than 4 different subs/mechanisms that are loaded like this: $ grep _fetch_sub dist/Carp/lib/Carp.pm sub _fetch_sub { # fetch sub without autovivifying if(defined(my $sub = _fetch_sub utf8 => 'is_utf8')) { if(defined(my $sub = _fetch_sub utf8 => 'downgrade')) { (_fetch_sub B => 'svref_2object' or return '') my $sub = _fetch_sub(overload => 'StrVal'); Some of them appear to be related to back-compat, but some of them are just egregious reimplementation of another modules functionality for the purpose of avoiding that module: # The downgrade() function defined here is to be used for attempts to # downgrade where it is acceptable to fail. It must be called with a # second argument that is a true value. BEGIN { if(defined(my $sub = _fetch_sub utf8 => 'downgrade')) { *downgrade = \&{"utf8::downgrade"}; } else { *downgrade = sub { my $r = ""; my $l = length($_[0]); for(my $i = 0; $i != $l; $i++) { my $o = ord(substr($_[0], $i, 1)); return if $o > 255; $r .= chr($o); } $_[0] = $r; }; } } I dont see any explanation for these shenanigans in the module, and instead of "playing along" with some unstated justification for this and unrolling a large part of overload.pm innards into Carp, I plan to just use overload.pm and break this expectation. Around the same time I was thinking about this Zefram then bumped into/mentioned this issue in this ticket, and I figured I would raise my objections to the premise and get a dialog going about why this is even necessary. If there is a good reason for these measures then I would expect it to be documented in Carp.pm, since it isnt documented I assume there isn't a good reason, and if there isn't a good reason then we should stop caring about it at all, and maybe rip out the complicated and inefficient and duplicative logic. So if there is a good reason please explain before I waste my time. On the other hand, if there isn't a good reason lets stop wasting our time with trying to support this objective. Why should it matter if Carp.pm unilaterally loaded overload.pm when first used? For that matter, why should Carp be lugging around code to support 5.6 when we are preparing to release 5.28? cheers, Yves .Thread Previous | Thread Next