Shadowing does not apply to CLONE

[ribasushi]

See the actual calling convention. Marking shadowing makes no sense, as threads.pm will invoke all CLONE's found regardless of @ISA

[kentfredric]

There's quite a few subs that this logic applies to:

• DESTROY
• Moo/Moose BUILD

And pretty much anything that manually does mro lookup and calls the entire stack in whatever order.

I think this is best left "in", as for end users, who are calling functions directly, it remains true.

( That is, if you manually call $PACKAGE->CLONE , you will still only get the top-most version )

Codifying the implied conventions of all subs that could be called by some other call ordering seems outside the scope of what can be determined here.

[ribasushi]

There's quite a few subs that this logic applies to:

You are wrong.

DESTROY

The above is an instance method, i.e. $self is passed in and is an actual instance (blessed ref). Calling ::SUPER / next::method would do something.

Moo/Moose BUILD

This is closer to how CLONE behaves, the difference being that it still operates on individual instances. Calling ::SUPER / next::method is stupid, but there are convoluted cases where it makes sense... I think.

CLONE on the other hand is a class function, and is never called by perl (the interpreter) with a specific argument. Hence why I opened the ticket - shadowing makes no sense in this context.

[ribasushi]

Also Moo/Moose's BUILD is not... exclusive. I.t. a hierarchy could have a sub BUILD {} which has fuck-all to do with Moo*, and everything will work correctly and shadowing will apply. CLONE is not such a case - the moment someone launches a thread - sparks will fly.

[kentfredric]

CLONE on the other hand is a class function, and is never called by perl (the interpreter) with a specific argument.

But it is called by the perl interpreter, and only by the perl interpreter, in this fashion.

I don't see any documentation that indicates that end users should be calling PACKAGE->CLONE() explicitly.

It looks more like "SUB NAMES AS SYMBOLIC API", not some inherent property of it being a sub in the context of plain Perl MRO.

And that's why I chose my examples the way I did. That the other examples are used as instance methods is independent to this point.

Because Perl doesn't actually have a way to define a sub as "a method", or "a function", or "an instance method" or "a class method". Which you get is entirely dependent on the calling convention you use.

Here, I just see "CLONE" as "Sub that has a specific known calling convention which is non-inheritance based".

I can consider special-casing CLONE in some way, I'm just not exactly sure how best to handle it.

Because if I say "Hey, shadow logic doesn't make sense because a thing calls this in a way that doesn't apply shadow logic", then by proxy, there's a few other places I should consider exposing that fact in some way.

Obviously the difference between BUILD and CLONE is BUILD is a "may be called by some OOP thing" whereas CLONE is a "Will be called by Perl", so CLONE is a more binary and clear usecase than the others.

Just doing this in a way that is consistent and not filled with lots of special cases is where I'm currently a bit perplexed.