Front page | perl.perl5.porters |
Postings from November 2016
Aaron Crane wrote: >containing an initial implementation of introspection for core >subroutine signatures. Terrible idea. A signature is a sub's implementation of part of its behaviour, not public metadata. The same thing can be implemented in other ways, and the choice of implementation is, and should remain, an internal matter for the sub. A sub should be able to switch between implementations without callers seeing any change in the API. It may be reasonable to add metadata fields to subs that correspond to some of the things you're picking out from the signature. If so, they should be justified in these terms: as metadata that a sub can advertise as part of its API. It should then be possible to populate these fields appropriately on any sub, whether or not it uses a signature. XS subs should be able to provide this metadata, Perl subs not using signatures should also be able to, and even Perl subs that are implemented using signatures should be able to set these fields differently from what the signature implies. Where a signature implies a specific value for one of the metadata fields, it is OK to have some mode in which the field is by default set according to the signature for subs that use one. But this mode shouldn't be the default under existing pragmata, because for this information to be advertised in public metadata would be a significant change in the semantics of existing signatures. >* cv_min_arity($coderef) >* cv_max_arity($coderef) Treating these as sub metadata, what's the intended semantic for callers? Clearly there can't be a guarantee that the sub will accept any number of arguments in the advertised range, because there isn't a well-defined concept of accepting arguments. A set of arguments can always be rejected for semantic reasons other than their count. Is the sub guaranteeing that it will die if given a number of arguments outside the stated range? It doesn't seem all that useful to merely have a guaranteed way of generating an exception; we've already got die() if we want to do that. It seems to me that this metadata isn't at all useful to other code at runtime. Its real value is as an advisory to the programmer: a development tool can introspect on the sub to catch dubious calls prior to runtime. Of course, the value is limited by the fact that a call such as "foo(bar())" could pass any number of arguments to foo(), due to list context. Prototypes already provide arity advice that development tools can (and perl itself does at compile time) pick up on, and by affecting context they make arity mismatches spottable at a much higher proportion of callsites. So the arity metadata that you propose isn't looking compelling. The proper default, for a sub that doesn't elect to supply specific arity metadata (a sub that "has no signature" in your proposal), depends on the intended usage of the metadata. If it's about guaranteeing to signal an exception for bad argument lists then your proposed 0/Inf default is fine. But if it's advice to the programmer, then it's more useful to have a distinct state that says "this sub does not supply this information". It is useful for the programmer to distinguish between "this sub puts no restriction on the number of arguments" and "argument count metadata is not available for this sub". >* cv_slurpy($coderef) Many of the same issues apply. The existence of a hash-like tail to the argument list structure is useful information to the callsite programmer during development, but not really usable by code at runtime. The same information is already advertised in some form through prototypes, and prototypes make it easier to apply this knowledge. One should distinguish between "no hash-like tail" and "information not available". Knowing that there is a hash-like tail on its own isn't much use: to apply the knowledge requires knowing at what parameter index this tail starts. Your proposed arity metadata doesn't cover this. -zeframThread Previous | Thread Next