Front page | perl.perl5.porters |
Postings from July 2014
On 30 Jul 2014, at 16:09, Jarkko Hietaniemi <jhi@iki.fi> wrote: > Time::Piece was an attempt in ["best practice"] > > Though I'd like to squeeze in #4.5... "modules where tight bundling with core is necessary/useful", like the B:: > > I'd be all for squeezing out all that do not pass #1-#4. But backward compat: at what release would we set the "grandfather line"? So my updated hierarchy, given some of the comments yesterday: 1. Needed to install perl (Test::Harness) 2. Considered part of the language (strict/warnings) 3. Toolchain modules needed to bootstrap your installation (CPAN) 4. Dependencies for any of the above (HTTP::Tiny) 5. Modules for talking to your environment (Cwd, File::Spec*) 6. Developer / introspection (B::, Module::CoreList) 7. Codifies best practice / language extensions (autodie) 8. "Batteries included" Feels like there's strong agreement on 1-6, but not on 7, and definitely not on 8. This made me wonder: what are the most-used modules (on CPAN) that aren't in core? They would be candidates for 7 and 8 above. Here's the top 20: Test-Pod 3480 Moose 2321 Test-Pod-Coverage 1981 libwww-perl 1816 URI 1432 Pod-Coverage-TrustPod 1374 Test-Exception 1266 Test-CPAN-Meta 1225 JSON 1057 HTTP-Message 911 namespace-autoclean 824 perl_mlb 781 DBI 770 Try-Tiny 752 Moo 701 DateTime 683 List-MoreUtils 668 Class-Accessor 649 Dist-Zilla 619 Path-Class 578 Some of those are definite "oof, no way *that* is going in core". And I'm repeatedly surprised that DateTime isn't in core, but then again I'm not. The two that feel like the easiest candidates are URI and Try-Tiny, but most people reading this would pick a different 2 from the list :-) Some good points in the article that Rik referenced[1]. For example: Programmers are reluctant to write libraries that duplicate [core libraries], so poor libraries in the standard set persist. Only a few people [...] are willing to write modules that compete with the standards. I don't think we have the problem of people not writing competing modules (I'm working on a review of Exporter modules, and there are 44 I've found so far!), but more that modules don't get widely used, because they're not in core. This is particularly true for things like Exporter modules. Bringing in fresh modules to compete with things already in core might not be a bad idea, in moderation. But as I go through more exporter modules (and look at their code, xdg!), I think "yeah, this one's got some good points, but ..." (no, I haven't got to Exporter::Tidy yet, Yves :-). Maybe I'll hit one where I think "perfect, here's the one to add to core!", but to be honest I'm not expecting that. Writing a module *for core*, like HTTP::Tiny was done, seems like a good approach to keeping core moving forward and bringing in modern thinking / practices, without bloating. The article also points out that "Once a library is enshrined in the standard set, it can’t change radically because too many programs rely on it", which strongly applies to Exporter modules: you can extend but you can't change incompatibly. Neil [1] http://www.leancrew.com/all-this/2012/04/where-modules-go-to-die/Thread Previous | Thread Next