Front page | perl.perl5.porters |
Postings from November 2016
On 24 Nov 2016, at 19:56, Zefram <zefram@fysh.org> wrote: […] > arc's usage implies that the arity metadata would > be part of the sub's API, and that change or withdrawal of the advertised > arity would be an incompatible change that should not be made in a module > update. If use of the information is acceptable and the arity comes only > from the signature, as arc proposed, then the use of a signature and the > (minimum?) arity of the signature become such unchangeable parts of the > API, with the adverse consequences that Abigail and I have described. Surely this is backwards? If anything, the fact that a sub’s parameters can be introspected makes it *easier* to change them, because you can expect (some of) the code calling that sub to introspect the required parameters and adjust its own behaviour accordingly, rather than hard-coding which parameters it supplied? Supposing you have a CPAN module Foo that has a method process_things that in version 0.1 took two parameters, and in version 0.2 takes three. (Let’s assume that they’re all the same type of parameter, e.g. process_things is being called on an array slice an arbitrary number of times until the array is all done.) Without subroutine signatures and being able to introspect them, Foo version 0.2 has to be able to recover from only being given two parameters, and code that calls foo->process_things with three parameters needs to say use Foo 0.2 to make sure it’s not accidentally run with Foo 0.1. With subroutine signatures introspection, Foo’s documentation can say “takes a number of parameters; this may vary from one implementation to the next, so use signature introspection to work out how many arguments to supply”. I’m not sure how useful this would ever be - I can’t really see production code ever using subroutine signatures to work out which arguments to pass to a third-party subroutine. It sounds like the old argument in favour of XML schemas, that code would magically know how to talk to other code because the schema would tell it how. The calling code might know what the variables should be, but unless it can also work out what to put in them, there’s not much point. But I don’t see how it would be actively harmful. Sam -- Website: http://www.illuminated.co.uk/Thread Previous | Thread Next