develooper Front page | perl.perl5.porters | Postings from January 2022

Re: arity checking (was Re: PSC #049 2022-01-07)

Thread Previous | Thread Next
From:
Tom Molesworth via perl5-porters
Date:
January 21, 2022 18:20
Subject:
Re: arity checking (was Re: PSC #049 2022-01-07)
Message ID:
CAGXhHdk79s=SV2eCz7njR4ThDCBTQETNFZL2-6KwhZoiD1nVsQ@mail.gmail.com
On Sat, 22 Jan 2022 at 01:49, Dave Mitchell <davem@iabyn.com> wrote:

> On Fri, Jan 21, 2022 at 06:29:27PM +0100, demerphq wrote:
> > So consider, I own a framework whose api is that I accept a callback from
> > the caller. I tell the caller that my api will call his sub with 1
> > argument, lets say "key".
>
> There's the crunch. If your framework promises to call always with one
> arg, then if you call the callback with 2 args, you've broken your
> promise.
>

Do you have examples of such frameworks, where there's an explicit promise
of never adding more args? (rather than saying "this takes 1 argument" with
"at the moment" being implicit)

If those exist, I believe those are the exception, rather than the norm.

Anyway, this thread seems to be repeating what was discussed very recently
- see
https://www.nntp.perl.org/group/perl.perl5.porters/2022/01/msg262413.html
for an example use-case.

Your eval workaround assumes that the directly-called sub is the only
possible thing which can throw the exception - what if that's triggered by
a sub further down?

I ended up writing
https://metacpan.org/dist/Acme-Signature-Arity/view/lib/Acme/Signature/Arity.pod
as a proof-of-concept API, but would hope that core Perl will expose some
sort of arity inspection in due course. Ignoring this library-extensibility
use-case while simultaneously promoting signatures as a complete
replacement for @_-based subs seems less than ideal to me.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About