Front page | perl.perl5.porters |
Postings from November 2016
Re: RFC: core sub signature introspection
Thread Previous
|
Thread Next
From:
Zefram
Date:
November 24, 2016 19:56
Subject:
Re: RFC: core sub signature introspection
Message ID:
20161124195636.GM6488@fysh.org
demerphq wrote:
>Does it? I don't see why. If someone did that to my code I would just
>say "you get to keep both pieces when it breaks".
arc's suggested iterate() function, for example, does that. It uses sub
metadata, that he proposes would come from the signature, in order to
formulate calls to the sub. If one constructs a correct use of iterate()
on a particular sub, then one is relying on the arity metadata for that
sub being as expected. Any change or withdrawal of the arity metadata
would break the user of iterate(). arc not only presents this as an
acceptable use of the metadata, he proposes it as *motivation* to expose
parts of the signature.
Your view expressed above implies that iterate() is not an acceptable
usage of this metadata. 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.
If any metadata such as arity is exposed, we do need to be clear about
whether it counts as part of the sub's API. If your view prevails,
we'd plaster the documentation with warnings along the lines of "these
results are not guaranteed, may change between versions of the operand
sub, and must not be relied upon for any operational purpose". But I'm
not convinced that that would be sufficient. The signature-based metadata
extraction interfaces would be attractive nuisances. People would rely
on them anyway, on the basis that they must be intended for *something*,
and your view makes them pretty useless.
>And I don't see how introspecting signatures is any different from
>them dumping out the code of your sub.
The difference is that you're picking out the signature as something
distinct from the rest of the body, implying that it is somehow
useful in isolation. When introspecting into the body qua code,
it is clearly understood that this is internal to the sub, is liable
to change, and must be examined as a whole to learn anything useful.
If there is support for extracting the signature alone, and even more
so parts of the signature such as minimum arity, then it encourages the
use of that information on its own, separate from the rest of the body.
It grants the signature an undue and misleading significance.
If signature-derived metadata should not be used for operational
purposes such as arc's iterate(), then the valid uses for signature
metadata per se are vanishingly obscure. (Much more obscure than uses
for introspection into the body as a whole.) These uses surely do not
warrant adding a core interface to extract (parts of) the signature of
a sub. They are adequately satisfied by the existing ability to walk
an optree and thus introspect into a sub body, which does not function
as an attractive nuisance.
-zefram
Thread Previous
|
Thread Next