|
Re: ::Tiny modules namespace origins
by choroba (Cardinal) on Oct 08, 2020 at 09:39 UTC
|
Please don't use ::Tiny unless it meets the ::Tiny criteria, thanks!
Here are the rules Adam Kennedy originally defined for what ::Tiny means:
- The module should be implemented in "as little code as possible"
- The module should implement a useful subset of functionality
- The module should use at least 1/10th the amount of memory overhead, ideally less than 100k
- The module MUST have no non-core dependencies
- The module MUST be only one single .pm file
- The module should be back-compatible to at least 5.004
- The module should omit functionality rather than implement it incorrectly.
- If applicable, the module should be compatible with the larger module.
See also the talk about Acme::Tiny by xdg.
map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
| [reply]
[d/l] |
|
|
| [reply] |
|
|
| [reply] |
Re: ::Tiny modules namespace origins
by Discipulus (Canon) on Oct 08, 2020 at 09:37 UTC
|
Hello Smonff,
David Golden here states:
> Adam Kennedy was annoyed that a config file loader had a huge memory footprint - Config::Tiny was born
Infact in Config::Tiny we can read:
> The *::Tiny family of modules is specifically intended to provide an ultralight alternative to the standard modules.
And finally some rule found at blogs.perl.org
Here are the rules Adam Kennedy originally defined for what ::Tiny mea
+ns:
1-The module should be implemented in "as little code as possible"
2-The module should implement a useful subset of functionality
3-The module should use at least 1/10th the amount of memory overhead,
+ ideally less than 100k
4-The module MUST have no non-core dependencies
5-The module MUST be only one single .pm file
6-The module should be back-compatible to at least 5.004
7-The module should omit functionality rather than implement it incorr
+ectly.
8-If applicable, the module should be compatible with the larger modul
+e.
L*
There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
| [reply]
[d/l] |
|
|
| [reply] |
|
|
Since you're interested in art and OuLiPo you might enjoy The Lighter Side of Perl Culture (Part III): Obfu - which notes that the Paris Perl Mongueurs have a long-standing interest in both OuLiPo and Perl obfu. Both BooK and stefp helped me a lot with that article and I was very grateful for their assistance. BooK was the one who pointed out the similarities between Perl obfu and OuLiPo as an art form, both being based on constraints.
| [reply] |
|
|
What's the reason to conform to so old version of Perl? As far as I know, these days all modern systems come with Perl 5.14+ at least. This century I've seen Perl 5.8 on board of Solaris only.
| [reply] |
|
|
As far as I know, these days all modern systems come with Perl 5.14+ at least.
Not everyone has the luxury of working on modern systems.
This century I've seen Perl 5.8 on board of Solaris only.
5.10 wasn't even released until the end of 2007 therefore everything released before that will have used 5.8 or an even older version. RHEL5 used 5.8 and some of those boxes are still supported under ELS.
All that said, I don't see much value in supporting (or trying to support) anything older than 5.8 for any new modules written today. The stipulation about ::Tiny was put in place years ago and time doesn't stand still. Perhaps the new steering committee could look to revise the official guidance once they are done with Perl 7.
| [reply]
[d/l] |
|
|
|
|
In practice, most ::Tiny modules only support as far back as toolchain currently does: 5.8.1.
| [reply] |
Re: *::Tiny modules namespace origins
by soonix (Canon) on Oct 08, 2020 at 18:36 UTC
|
I think there was some discussion a while ago, that the "Simple" modules are sometimes "too simple" and inflexible if/when circumstances change.
More or less, the "Simple" modules usually make "their" thing simple to use, by including boilerplate/wrapping default behaviour around a complex thing (which makes it more difficult to deviate later, when it may be necessary).The "Tiny" modules more or less give you only the bare necessities to build upon, which enables you to start simple and later make it just as complex as needed. | [reply] |
Re: *::Tiny modules namespace origins
by perlfan (Vicar) on Oct 08, 2020 at 18:19 UTC
|
I think that the market of users will decide. I assume the best of intention for the module author. The proof of it's usefulness (presumably due to it's tiny footprint) is that it will get used. In the case of HTTP::Tiny, it was used so heavily that it was rolled into core. Also note, there are ::Fast, ::PP (pure Perl), and ::XS traditions as well, for example: Class::Accessor::Fast, Date::Pcalc, JSON::PP/JSON::XS. | [reply]
[d/l]
[select] |
