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