A plugin system for your Perl framework or application
Changes for 0.000001 - 2024-03-02
- Another early release, almost nothing is implemented yet.
Mojolicious plugin providing access to an OpenAPI document and parser
Changes for 0.009 - 2024-04-06T23:09:07Z
- adjust tests for changes in OpenAPI::Modern 0.062
like this
reshared this
find perl root and push lib modules path to @INC
Changes for 0.07 - 2024-04-06T22:36:14Z
- update docs, describe the features / parameters
- add function rootdir as alias for function root
- update a test to use rootdir instead of root
- add an env flag that indicates test mode for caller_file param
generate short unique identifiers from numbers
Changes for 0.03 - 2024-04-06T22:09:57Z
- Fix typo in POD
Greetings monks, question about reorganizing a Perl module, and if the following is a good approach:
The module is 7300 lines in one file and has 106 subs. I'll call it Cat.pm, its mostly called as an object like Cat->new(); but could be called like Cat->black() or Cat::Black::meow
To simplify maintaining this file I am thinking I can make a new sub directory in the same folder as the file call it Cat/ and move the 105 of the 106 subs to about 12 or 15 new .pm's in the new folder.
I plan later to rewrite one or more of those as XS modules. Cat/Tabby_XS.pm etc.
Then in Cat.pm I would just have use Cat::Black; use Cat::White; use Cat:;tabby; ...etc in Cat.pm
The only sub I'd keep in Cat.pm is sub new which looks like this:
sub new { #Object Interface #http://www.perl.com/pub/1999/09/refererents.html my $type = shift; my $self = {}; $self->{dbh} = shift; bless $self, $type; $self; } I have a book on cleaning up old perl code but it is now a very old book LOL, will moving the subroutines to new files break old code that depends on Cat.pm? TIA
submitted by /u/bug_splat
[link] [comments]
