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:
Dave Mitchell
Date:
January 21, 2022 16:26
Subject:
Re: arity checking (was Re: PSC #049 2022-01-07)
Message ID:
Yereqg8KxKWBd3Sy@iabyn.com
On Fri, Jan 21, 2022 at 03:15:31PM +0100, demerphq wrote:
> On Fri, 21 Jan 2022 at 14:12, Nicholas Clark <nick@ccl4.org> wrote:
> 
> > Really you want to know you have a problem *before* you call the callback
> > (ie what Yves wrote - you want to be able to flag a problem at object
> > construction time, which might well be program startup. Not fail at
> > runtime,
> > unattended, into a log file or even /dev/null)
> >
> 
> So am i correct in understanding that you would be ok with exposing an API
> to check the subs arity signature? If so then I'll try to think up
> one (others could too).

But this is a general problem, not just one with signatured subs. A
"normal" callback sub could be written as:

    sub callback {
        croak unless @_ == 2;
        (my $self, $foo) = @_;
        ...
    }

How would the caller (say an event handler module), which has been upgraded
to pass an optional next arg, know that the callback sub it wanted to call
would croak on that extra arg?

I think in the past that strong opinions have been expressed against
allowing a signature API which a caller can use to inspect a sub, on the
grounds that really the sub signature is an implementation detail - just a
fancy and fast way of writing a @_ unpacker, and in general, doesn't form
a promised API.

-- 
You're only as old as you look.

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