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 https://rt.perl.org/Ticket/Display.html?id=132902Thread Previous | Thread Next