Subtle advantage of @_ ?
It eliminates method polymorphism.
Makes it simple for over-riding inherited method, as there is only one method.
Now that makes Liskov Substituion simpler to implement.
I blog about Perl.
Free blog hosting for users of the Perl Programming Language
But that’s only simpler from the point of view of perl, but not that of Perl code. Instead of writing several candidate methods with different signatures and letting the dispatcher pick one of them – declaratively –, you throw away the dispatcher and let the Perl programmer unpack
@_and inspect it to choose a branch – imperatively.And Liskov substitution is not about passing the compiler’s bar. It’s about whether the semantics are preserved. So it is completely unrelated to how a programming language. Static or dynamic types, explicit or implicit, weak or strong, signature overloading, multiple dispatch… you name it, and none of it makes a whit of difference. The question isn’t “will the compiler let me do this?” (because if it doesn’t, the program won’t compile in the first place, so none of this deliberation is necessary) – the question is “the program may be valid, but will it do something reasonable, or does it have subtle semantical inconsistencies at a level that is inaccessible to the compiler?”.
> But that’s only simpler from the point of view of perl, but not that of Perl code.
True. I missed that.
> ... Instead of writing several candidate methods with different signatures and letting the dispatcher pick one of them ...
I think its letting the "automatic" dispatcher pick, that is the source of my discontentment. By automatic I mean something which is under the control of the compiler and not the *programmer*.
Trivial Case, what if I wanted the dispatcher to ignore all the arguments and call the Child's method ? In the "automatic" dispatcher, which tries to *enforce* the LSP through the compiler and function signatures, I will have to either
1) Write a dummy method which takes an argument and *ignoring* the argument which calls the child method without arguments.
2) Add a dummy argument to all the Child's methods
3) Make an Interface and force the Child and Parent to follow the same interface.
In perl, the problem would never arise (you write the dispatcher manually!). Its not an advantage as such, but it makes a (poor) hack that works possible.
If I am not mistaken, Ruby and Python will throw an error saying "method with so and so arguments not found", since they use method signatures to *blindly* detect the class.
> And Liskov substitution is not about passing the compiler’s bar. It’s about whether the semantics are preserved.
I agree.
The argument is actually, Declarative Signatures(mercy of the compiler) vs Imperative Signatures(merit of the programmer).
Declarative signatures limit the total cases of LSP is my argument. It is a good thing, but I can think of one or two exceptions to the rule.