On Sun, May 7, 2023 at 6:13 AM Marc Espie <marc.espie.open...@gmail.com>
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
