Front page | perl.perl5.porters |
Postings from January 2022
RFC: Amores. Introducing a `module` keyword
Thread Previous
From:
Aaron Priven
Date:
January 25, 2022 23:08
Subject:
RFC: Amores. Introducing a `module` keyword
Message ID:
2347BDC0-34F6-44AE-9FEB-EAFF5E45B9D2@priven.com
Some issues / questions about this idea. I agree with others that there are a lot of different ideas here that could be broken down and considered separately.
1) module keyword
I don’t like the term package much, but “module” is currently used to refer to a group of files distributed together (e.g., https://www.cpan.org/modules/index.html ) and I think using it here would just invite more confusion.
Maybe “toolbox” is a good word for a collection of functions?
There are some things that both export a function and are also classes (e.g., Path::Tiny), and I’m not sure how any new keyword would deal with that.
It seems to me that all the actual advantages of having a new keyword were listed under “Scope for future work” (such as inner modules) and there’s no particular reason to not allow something declared with package to, e.g., export via an attribute.
2) attributes on packages/modules
I could imagine using those for other things so I think that makes sense to have in a new keyword, or to add to package if it can be done without breaking backward compatibility.
3) exporting via attributes
I like the idea of exporting with this syntax, but I have a number of questions with the proposal.
Exporter is just one module used for exporting, and there are other ones with much more functionality (e.g., Sub::Exporter or Exporter::Tiny). Could another module intercept whatever it is that would handle the :export attribute in Amores? Would some of the additional features (“-as”, “-prefix”, “-suffix”) be available in Amores exporting?
Listing exports is just one of the many uses of the argument list in “use”, since the “import” sub can do whatever it wants. How would whatever handles exporting distinguish between exports and other arguments to “use”?
The proposal is to have :export(tag), which implies that a tag is a literal. How can a tag be built programmatically? Will :export($tag) work? How about :export(tag1, tag2) ?
It occurs to me that one could have, on the module/package declaration, an attribute that would export all subs, or export all subs whose names don’t begin with an underscore.
4) requiring the use of a postfix block instead of, as with package, “from here to end of scope"
Even if one could fix the automatic formatting tools to ignore the outermost braces, it would still be irritating boilerplate to have to put a trailing brace at the end of every module. Isn’t getting rid of irritating boilerplate part of what this proposal is about?
--
Aaron Priven, aaron@priven.com, www.priven.com/aaron
--
Aaron Priven, aaron@priven.com, www.priven.com/aaron
Thread Previous