Front page | perl.perl5.porters |
Postings from November 2016
On 24 November 2016 at 11:21, Abigail <abigail@abigail.be> 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.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next