develooper Front page | perl.perl5.porters | Postings from April 2022

Pre-RFC: a `library` keyword

Thread Next
Ovid via perl5-porters
April 1, 2022 09:22
Pre-RFC: a `library` keyword
Message ID:

My last attempt at this was met with interest, including recommendations to write up a full RFC (, but ultimately declined.
The key paragraph:
> So in its current form, we've marked this as rejected, but we think this is an> area that's ripe for more thought. Part of that should include a review of> CPAN and the problems with the current options. Finally, we agreed that in> whatever form, we're not likely to ever accept a `module` keyword to mean "a> collection of functions", given the established definition of "module".
The Problem
There are two problems which frustrate me tremendously, but can both be solved with a single keyword.
First problem: I would like to sit down and start writing "modern" Perl without having to manually type (and possibly forget) a bunch of boilerplate to write "sane" code. The `Modern::Perl` module tries to help with this. I have a personal module named `Less::Boilerplate` which helps to do this.  `strictures` has a similar idea, though with a different focus. Numerous other modules, such as Moose or various Mojo modules approach this in a slightly different way, but coupled to those modules.
Second problem: I would like a better way of organizing my code, including the ability to create lexically-scoped packages that do not show up in a namespace. Per my proposal below, I have not found any CPAN modules which address this (maybe they're there, but I haven't found them).
The Proposed Solution
I believe both of the above problems can be solved with a single keyword: library. This is largely modeled after Java inner classes, but adapted for procedural code.
Stub grammar:
    use feature 'library';
    library Mungifier v1.2.3 {        sub foo($bar) { ... }
        # Exposed as Mungifier::String, though you can use a proper        # fully-qualified package name if you prefer (easier refactoring)        library ::String { # Exposed as Mungifier::String            sub this (@args) { ... }
            # the following is only available in the Mungifier library and            # contained libraries            sub that (@args) :trusted { ... }
            # the following is only available in Mungifier::String            sub what (@args) :private { ... }        }
        # Only available to Mungifier and inner libraries (as        # Mungifier::Utils)        library ::Utils :trusted {            ...        }    }
For the current proposal, the syntax for using an inner library's functions will use Perl's current mechanisms (fully-qualified function name or exporting). I'm unsure how this will work with :trusted packages because the consensus seemed to be that we should improve exporting in a separate RFC.
   - Significantly reduced boilerplate.
   - Lexically-scoped effects, not bleeding into the rest of the program
   - Private utility modules/functions don't accidentally become part of the public API (!)
   - Strict, warnings, utf8 source, signatures, and "no feature 'indirect'" by default (what else?)
   - Yields a `1` to avoid needing to add `1` at the end of every file
   - As library-based .pm files grow too large, the developer can still move inner libraries to separate .pm files
   - Public relations: Perl is still evolving
   - Many devs object to mandatory postfix blocks
   - The :trusted/:private modifiers have enough subtle issues that we might exclude them at first
   - Unknown if the `library ::String {}` syntax for an inner library would be problematic
Best,Ovid-- IT consulting, training, specializing in Perl, databases, and agile development 
Buy my book! -

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About