On Mon, May 08, 2023 at 01:23:25AM -0400, George Koehler wrote:
> On Sun, 7 May 2023 19:21:11 -0700
> Philip Guenther <guent...@gmail.com> wrote:
> 
> > On Sun, May 7, 2023 at 6:13 AM Marc Espie <marc.espie.open...@gmail.com>
> > wrote:
> > 
> > > I'm actually wondering whether keeping the prototype is worth it.
> > ...
> > For plain subs, I would only keep them if they _really_ help the calls look
> > for more perl-ish, by whatever scale you currently measure that.  Maybe a
> > (&@) prototype so you can do "mysub { s/implicit/sub here/ } qw(args here)"
> > ala map and grep, but...eh.
> 
> I wrote some (&@) prototypes before v5.36,
> 
> | use v5.28;
> | use warnings;
> | use experimental 'signatures';
> |
> | sub bsearch :prototype(&@) ($block, @list) { ... }
> | sub bsearch_range :prototype(&@) ($block, $low, $high) { ... }
> 
> The signature checks that bsearch_range has exactly 3 arguments.
> 
> I sometimes call subs with the wrong number of arguments.  My other
> frequent mistakes in Perl are syntax errors, strict(3p) errors, and
> warnings(3p) of uninitialized values.
> 
> 
I was always using strict and warnings unless I forgot.

I've got a few (very few) tricky uses on prototypes.
I might fix them as a switch to v5.36 before doing anything else!

(so far, the main abuser of perl funky syntax is the system stuff in State...
Not convinced about any other "regular" way of doing things, though I might
decide to try for a hash with names as first part, since the part that's run
in child/parent isn't obvious)

(the other sticky part is native sig handlers not having clear signatures
thanks in parts to WARN/DIE)

Reply via email to