Front page | perl.perl5.porters |
Postings from April 2022
Pre-RFC: a `library` keyword
Thread Next
From:
Ovid via perl5-porters
Date:
April 1, 2022 09:22
Subject:
Pre-RFC: a `library` keyword
Message ID:
930668636.366392.1648804957355@mail.yahoo.com
Preface
My last attempt at this was met with interest, including recommendations to write up a full RFC (https://www.nntp.perl.org/group/perl.perl5.porters/2022/01/msg262537.html), but ultimately declined. https://www.nntp.perl.org/group/perl.perl5.porters/2022/02/msg262764.html
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:
'library' PACKAGENAME VERSION? BLOCK
Example:
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.
Benefits
- 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
Problems
- 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 developmenthttp://www.allaroundtheworld.fr/.
Buy my book! - http://bit.ly/beginning_perl
Thread Next
-
Pre-RFC: a `library` keyword
by Ovid via perl5-porters