Front page | perl.perl5.porters |
Postings from January 2022
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