I've still been thinking about proper OO in the Perl core and hit an interesting case.

Imagine the following, hypothetical Perl 5 OO syntax. Inheritance is handled via is and inheritance order is assumed to parent class declaration order. Thus, UnlovedChild inherits from MissingFather first.

What do you think the output should be?

class MissingFather { method shout() { say "I'm outta here!" } } class DrunkenMother { method shout($message) { say "$message!" } } class UnlovedChild is MissingFather, DrunkenMother {} UnlovedChild->shout("Where's my beer?!")

I currently have this code mostly working locally and if you run it you get an error like:

`Too many arguments for subroutine 'MissingFather::shout' at ...

That's because method resolution in Perl is based on the name of the method (or, sadly, the subroutine) and we can easily select the wrong method. If we were to identify methods by name and arity (the number of arguments), we could say that MissingFather doesn't listen and thus has a shout/0 method while DrunkenMother just yells back whatever you say to her via shout/1 . It's quite reasonable to expect that when UnlovedChild shouts, his DrunkenMother shouts back at him because we tried to call shout/1 , not shout/0 , but because we inherit from MissingFather first, we get shout/0 and a fatal error, instead of the behavior we were looking for.

So if we go with arity-based method resolution (and C3), we can at least try to call the method the developers expect. I'm not saying this is perfect, but we can try. Even in a linear tree (A -> B -> C), calling a method on C might just skip a similarly named method in B and go straight to A because A matches the arity. This system works reasonably well for other languages, such as Clojure and Prolog. Further, because it's arity-based and doesn't require complex resolution, it should be simple to implement.

But there are some issues with this.

First, should we do this? The UnlovedChild behavior might be arguably wrong because:

Multiple inheritance is crap Even if it weren't, the child shouldn't really inherit from MissingFather and DrunkenMother as it might in the real world Having similar methods with different signatures might be viewed as a code smell (and starts taking us down the rabbit hole of multi-dispatch)

Second, if we use arity-based dispatch, what about forward declarations?

sub foo; # legal sub foo($bar); # no signatures allowed on forward declarations

Third, how does role-based composition work with arity? If your class consumes a role with a foo/2 method and you implement a foo/1 method, is that a conflict? If it isn't, we've a hybrid of identifying methods by name or name+arity. If it is, we've gone down the road of arity-based multi-dispatch. I imagine this would likely entail very, very significant changes to the Perl core.

And if you think we should get into types, and putting those into signatures, you can read more about the complexity of finding the right method.

I would love to hear your thoughts.