Re: converting perl stuff to v5.36
On Mon, May 08, 2023 at 01:23:25AM -0400, George Koehler wrote:
> On Sun, 7 May 2023 19:21:11 -0700
> Philip Guenther wrote:
>
> > On Sun, May 7, 2023 at 6:13 AM Marc Espie
> > 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)
Re: converting perl stuff to v5.36
On Sun, May 07, 2023 at 07:21:11PM -0700, Philip Guenther wrote: > Yeah, the downside of signatures is that by default it makes adding > parameters a breaking change and can thus calcify the interface. Something > for authors of shared modules that have callbacks to carefully consider. :/ So far, my stance on my code is that only stuff that's already in-tree matters. If people have external code, I'll be glad to fix things for them. "Bugs" in current code have been few and resulted in improvements in either documentation or interface in 99% of the cases. (and opening a constructor to extra params takes about 5 minutes)
Re: converting perl stuff to v5.36
On Sun, 7 May 2023 19:21:11 -0700
Philip Guenther wrote:
> On Sun, May 7, 2023 at 6:13 AM Marc Espie
> 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.
Re: converting perl stuff to v5.36
On Sun, May 7, 2023 at 6:13 AM Marc Espie
wrote:
> It is generally a good thing, I'm mostly talking about
> the "signatures" stuff that allows functions with stuff that looks like
> usual languages.
> Other benefits include somewhat "cheap" check for correct number of
> parameters
> and generally making code shorter.
>
Yep. The benefit that the latter is enforced on all calls, including
method calls (where prototypes did *not* apply) is great and caught several
mismatched calls in the source tree I work on at $DAYJOB.
(I also hope that the binding is/will become more efficient than writing
> stuff manually)
>
I think I saw something about "30% faster" for the binding operation(s) (on
some hardware, with some compiler...).
Stuff to watch out for:
>
> - it supersedes the syntax for prototypes. So if you had prototypes
> (I did!), you need to explicitly write :prototypes in front of them.
>
> For instance, constant methods like
> package X;
> sub is_okay()
> {
> 1;
> }
>
> would become:
>
> package X;
> sub is_okay :prototype() ($)
> {
> 1;
> }
>
>
> under the new rules.
> I'm actually wondering whether keeping the prototype is worth it.
>
For methods, the answer has to be "no", since the prototype has no effect
there. We found we had lots of prototypes in our tree which were actually
*wrong* and would have resulted in calls being rejected if prototypes
weren't ignored for methods.
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.
(Going forward, I probably wouldn't use an empty prototype directly without
thinking and maybe commenting why I _didn't_ do "use constant" instead.)
> - use v5.36; implies "use strict;" "use warnings;" and "use feature
> qw(say);"
> which is cool
>
Not just 'say' but the entire "use feature :5.36;" bundle. After
'signatures', 'state' is my favorite from that set, making one-line lazy
helper-object setup easy, ala:
sub someclass {
return state $someclass //= SomeClass->new({ blah => 'blah' });
}
sub anotherclass {
return state $anotherclass //= AnotherClass->new({ someclass =>
someclass(), other => 'stuff' });
}
(In a class, you would just make it a member and not need 'state', of
course.)
> - parameters which aren't used can use a single $ or something, which
> leaves
> the question of documentation.
>
> After fiddling a bit with it, I've settled on documenting the method
fully in comments, e.g., for instance:
>
Yeah, that's what I settled on too.
- lambdas (anonymous subs) can use signatures. Note that stuff like
> File::Find explicitly takes 0 parameters, whereas stuff like signal handler
> is woefully underspecified !
>
Yeah, the downside of signatures is that by default it makes adding
parameters a breaking change and can thus calcify the interface. Something
for authors of shared modules that have callbacks to carefully consider. :/
Philip Guenther
