develooper Front page | perl.perl5.porters | Postings from November 2016

Re: RFC: core sub signature introspection

Thread Previous | Thread Next
November 24, 2016 10:36
Re: RFC: core sub signature introspection
Message ID:
On 24 November 2016 at 11:21, Abigail <> wrote:
> On Sun, Nov 13, 2016 at 02:52:49PM +0100, Aaron Crane wrote:
>> I've just pushed a branch arc/smoke-me/signature-introspection,
>> containing an initial implementation of introspection for core
>> subroutine signatures.
> If code gets to introspect a subroutine signature, it's no longer
> the case that:
>     sub some_sub ($foo, $bar, $baz) {
>        ...
>     }
> is just a programmer friendly way of writing
>     sub some_sub {
>         my ($foo, $bar, $baz) = @_;
>         ...
>     }
> it suddenly becomes more. It becomes part of the API. Changing the
> name of a variable may break some code elsewhere. Variables which
> should be lexical, aren't.
> I really like subroutine signatures. But if that means that I'll have
> to a deprecation cycle just because I want to rename a variable which
> ought to be internal, I might as well not even start using signatures.

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".

Right now I can introspect your packages for global vars, and with
padwalker and possibly other tools I can introspect it for lexicals
too. Data::Dump::Streamer can dump out your subs with state even.

I don't see any of that a reason for someone to consider their lexical
var names part of their subs API.

And I don't see how introspecting signatures is any different from
them dumping out the code of your sub.


perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About