-
-
Notifications
You must be signed in to change notification settings - Fork 367
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decide on how to use (or not to use) Perl function prototypes or signatures #6956
Comments
Hi Stéphane, Answering here after reading the message on FR Perl Mongers mailing list.
The boilerplate pain can be reduced easily by using the trick described in Ovid's Enforcing Simple Standards with One Module blog post. This blog also gives interesting information about companies making the subroutines feature switch. One more reason to adopt: signatures went out of the experimental stage with perl 5.36 and declared a stable feature. Personally, I use them since they appeared (with 5.20), I don't have any complaints to express. |
That's great news IMHO. Using experimental features in a larger codebase can be bad, but using signatures would make the code more pragmatic. |
Hi @smonff , thanks a lot for your reply! The Veure::Module is interesting, maybe we could just use our own version of it (I couldn't find the Veure one on cpan so I assume it's internal). |
The source code looks to be in the blog post. I think we have something (partly) similar with the use of |
Ovid does mention this in the post:
Looks like Modern::Perl handles signature importing if we bump the feature to 5.34 We could indeed go for our own module if we have something to add to Modern::Perl, like the utf8 boilerplate. |
I never noticed how small the code for Modern::Perl is. :) I'd be in favour of just switching to: use Modern::Perl '2022'; So that new programmers don't have to look at what we put in our own module (which would just be "use utf8;" I guess). |
The most important aspect here is If you create your own |
Good news: the Perl signatures in their current form were introduced in Perl 5.24, which is the old Perl we have in production today. :) |
But "use Modern::Perl '2022'" does not work if Perl is not 5.34. Feature bundle "5.34" is not supported by Perl 5.28.1 at /opt/perl/local/lib/perl5/Modern/Perl.pm line 37. So I guess we just create our own Modern::Perl / Veure::Module then. |
I'll try it and make a PR for it. |
Yeah, it's basically just warnings->import;
strict->import;
feature->import( $feature_tag ) Just add signatures to that, and we have our own module. |
How does this look? |
* feat: enable Perl signatures #6956 * rename module to ProductOpener::PerlStandards * rename module to ProductOpener::PerlStandards
* feat: enable Perl signatures #6956 * rename module to ProductOpener::PerlStandards * rename module to ProductOpener::PerlStandards
* feat: enable Perl signatures #6956 * rename module to ProductOpener::PerlStandards * rename module to ProductOpener::PerlStandards
* feat: enable Perl signatures #6956 * rename module to ProductOpener::PerlStandards * rename module to ProductOpener::PerlStandards
* feat: enable Perl signatures #6956 * rename module to ProductOpener::PerlStandards * rename module to ProductOpener::PerlStandards
* feat: enable Perl signatures #6956 * rename module to ProductOpener::PerlStandards * rename module to ProductOpener::PerlStandards
We can close this, most code is migrated. |
Is your feature request related to a problem? Please describe.
In most of the Product Opener code, we use Perl prototypes to specify how many arguments functions have.
e.g.
This is something I believe is useful, because if the function is called with a different number of arguments, it will fail at compile time.
e.g. if I add this function in Display.pm
Then when I do "make restart", the container stops and I have this error in the logs:
But there are lots of threads on the Web that explain that Perl's prototypes are harmful / should not be used. e.g. https://stackoverflow.com/questions/297034/why-are-perl-5s-function-prototypes-bad
Describe the solution you'd like
I think we could just use the "experimental" signatures of Perl (that are in fact not experimental anymore in the just released Perl 5.36):
https://perldoc.pl/perlsub#Signatures
Any thoughts?
cc @hangy @alexgarel @zigouras
Describe alternatives you've considered
No response
Additional context
No response
Number of products impacted
No response
Time per product
No response
The text was updated successfully, but these errors were encountered: