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

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

Thread Previous | Thread Next
February 26, 2018 04:27
Re: [perl #132902] Blead Breaks CPAN: Class::Std
Message ID:
On 26 February 2018 at 05:02, Father Chrysostomos via RT
<> wrote:
> 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. :-)

Indeed. :-) Perhaps a bit too close to the machine version though. ;-)

>> 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.

I definitely agree with the latter two points. I am not entirely
convinced about the first one, but I can live your interpretation.

>> 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.

I agree with this.

>> 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.

I'm willing to bend over backwards as well, or I wouldn't have tried
to fix this in the first place. :-)

[ And really, that paragraph seems pretty close to suggesting I am
acting in bad-faith here, which I am most certainly not.]

The place I disagree is *not* about avoiding breakage, but rather
about the right way to do so. And even there, I would not actually say
I disagree with you, I just am not convinced yet and feel the subject
merits more debate than we have given.

In particular I feel that we are going through huge contortions and
complexity simply to avoid loading, and imposing
performance penalties on stack serialization to do so.

It feels like to me we have possibly already pushed past the point
where our efforts to avoid loading are more expensive than
just loading

So for instance, if I was able to show that adding a "use overload;"
to the Carp had negligble or positive load time consequences would you
concur that we should remove this complexity? If not, what would
convince you?

>> 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 think anything that overrides an Internals:: (or equivalent)
function gets to keep both pieces. And because said logic would not
reside in UNIVERSAL, it would not affect all the normal uses of can()
that we both agree should work.

>> I am right now quite baffled.
> Funny thing, I used the number 0xbaff1ed_bee in one of the tests.

:-) [ Interestingly some time back I was told by an academic that not
all language groups appreciate Irony the way English speakers do. ]

>> 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.

But that is my point, this patch sequence has had too many patches and
too little discussion. Maybe a bit more deliberation would improve the
quality of our work.

> I, too, intend to move on to more interesting things, after I’ve checked one other thing that may be broken in Carp.

Please lets resolve this discussion before you move on.

I appreciate your work and opinion, and I apologize if my attempts to
fix Carp have lead you to do more work, but at the same time, I note
that if we had just dropped the policy of eschewing "use overload;"
like I suggested in the first place /none/ of these patches or bug
reports would have happened.

So I feel like we really aught to address that point and come to a
consensus before we move on.

Which is why I cc'ed Sawyer on my last post, and why I am cc'ing him here.


perl -Mre=debug -e "/just|another|perl|hacker/"

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