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 26, 2018 04:02
[perl #132902] Blead Breaks CPAN: Class::Std
Message ID:
On Sun, 25 Feb 2018 16:14:44 -0800, demerphq wrote:
> I am really struggling to understand what you think is right.

Well, I can be enigmatic. :-)

> So first off, there are *two* UNIVERSAL::can()'s involved, the *real*
> one, in Perl. And the fake one, in the CPAN module UNIVERSAL-can.
> That module thinks that is "buggy" to call UNIVERSAL::can() as a
> function, which I definitely do not agree with, and is in fact what I
> think Carp should do for this check.

I agree with you here.

> In one of the other posts in this thread, you argue that can()
> implementations should not be aware of overload subs, but now you
> think the right thing to do is patch a /non-core module/ to be aware
> of them.

Regular modules’ ‘can’ implementations should not have to care about them.  Modules that meddle with UNIVERSAL::can need to bend over backwards to make sure they are not breaking things.  With great power (overriding UNIVERSAL) comes great responsibility.

> You also have said you think that UNIVERSAL::can() should not be used

I don’t think $some_object->can should be used.  UNIVERSAL::can($object, ...) should be fine.

I think this way, not because I think that a method designed to look for methods is a good fit for overloading, but because in this particular instance (core’s UNIVERSAL::can) it happens to do exactly the right thing.  And, in being a stable interface, we can depend on it.

> for things like $obj->can("((") because overload subs do not respect
> AUTOLOAD. (I don't agree with that either.)
> I do not see how it is right that a patch to a module not in core is
> required to fix behavior that is in core.

If merely loading some module (and a not-so-unpopular module) will break the core, and it didn’t in the previous Perl version, then what should be someone else’s problem (a broken override) becomes *our* problem.

You may disagree with that, but that’s fine.  I’m willing to bend over backwards to get things working.  You don’t have to.

> It seems to me that we need an exposure of UNIVERSAL::can() that does
> NOT live in the UNIVERSAL namespace and which cannot be overriden by a
> module, and that in future Perls we should use that in overload and in
> Carp.

We can’t stop buggy modules from overriding things.  But we can patch the one buggy module that currently does it to ‘can’.

> I am right now quite baffled.

Funny thing, I used the number 0xbaff1ed_bee in one of the tests.

> Honestly at this point I think the right thing is to make Carp load
> overload unilaterally and make Carp use that, and move on to more
> interesting things.

I fixed this a different way before I read your message.  I, too, intend to move on to more interesting things, after I’ve checked one other thing that may be broken in Carp.


Father Chrysostomos

via perlbug:  queue: perl5 status: resolved

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