develooper Front page | perl.perl5.porters | Postings from February 2018

[perl #132902] Blead Breaks CPAN: Class::Std

Thread Previous | Thread Next
Father Chrysostomos via RT
February 25, 2018 01:40
[perl #132902] Blead Breaks CPAN: Class::Std
Message ID:
On Sat, 24 Feb 2018 15:51:03 -0800, demerphq wrote:
> On 25 Feb 2018 02:01, "Father Chrysostomos via RT" <
>> wrote:
> > I don’t like the current state of the code in, but I can’t say I
> > have a better suggestion off the top of my head.  I have not thought it
> > through thoroughly yet.  Let me just outline my concerns, before I forget
> > them, and later if I have time I might come up with a patch:
> > 
> > if ($in_recurse || do{ local $in_recurse = 1; $pack->can("((") }) {
> > 
> > This will only work on newer perls (5.16+ iirc), since older ones used (),
> > not ((.  And I think even current perl allows XS modules to register
> > overloading via just (), without ((.  I need to check.
> We can add a check for () as well.
> > ‘can’ is really not the right thing to use.
> Can you explain why? Since overloads are inherited it seems there is no
> choice.

The text that follows was meant to be the explanation.  can and AUTOLOAD go together.  Since overloading does not use AUTOLOAD, using can to detect overloading can be problematic.

> >   Overriding ‘can’ makes sense in the presence of AUTOLOAD, but since
> > overloading bypassing AUTOLOAD, it should be bypassing ‘can‘ as well.  This
> > is why implements its own ‘can’.  Perhaps should be
> > loaded unconditionally when Carp is loaded (it is more lightweight than
> > Carp, after all).  Then theoretically one could use overload::Overloaded,
> > but unfortunately old versions have the same ‘can’ bug that will cause the
> > recursion.

Not just recursion.  Look at the test I added in e6bb0a40852.

> > Maybe calling overload::mycan directly is the solution.
> If Carp unilaterally loads overload we don't need to use can at all. The
> only reason we use it is to avoid loading overload when we don't need to.
> I already suggested that this policy was counter productive and the only
> reason I didn't change was that you expressed an opinion that we should be
> able to keep it.
> If you no longer care about loading overload then the patch becomes trivial.

Well, since Carp is used *everywhere*, I believe it should remain as lightweight as possible.  Now that I’ve had a chance to look at the code in more detail, I see that it only occurs for stack traces.  I am loath to force another module to be loaded, considering that many quick scripts never use stack traces.  But loading on demand in that case is itself problematic, since Carp is often called when things are in an inconsistent state.  You shouldn’t risk dying when trying to load something in order to report an error.  (Yes, this actually happened.  That’s why Carp::Heavy was eliminated.)

That said, I’m still on the fence about it.  I know Zefram cares about this sort of thing, too, so I would ask him which is the best approach:

• Go ahead and load unconditionally.  It’s already much smaller than Carp.

• Copy & paste mycan into Carp.  It’s just seven lines or so (but we need two versions depending on the perl version).

> > This is a real can of worms.
> A real mycan of worms?
> Yves

s/v//r is my answer. :-)


Father Chrysostomos

via perlbug:  queue: perl5 status: open

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About