Front page | perl.perl5.porters |
Postings from February 2018
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=132902
Thread Previous
|
Thread Next