A few years back there was an oft-cited sort-of rule (but maybe more of an aspiration) that we should only have modules in core that are needed to build perl itself or to install modules from CPAN. Obviously at the time we already have a bunch of stuff grandfathered in, and we didn’t even have a procedure for getting things back out. In part that was because it is actually very hard to really get things out once you consider perl at the OS vendor package level rather than just within the CPAN bubble. Even so, the rule leaves grey area around modules that implement things which are in some sense part of the language without being built into the interpreter directly, like Time::Piece being based on a old Larry design for localtime’s return value, or the Scalar/List/Hash::Util stuff (at least some of which really ought to have been inside the interpreter itself… an old story). Is Module::Runtime either of these? It does not seem that way to me. > Here's my basic pitch: The rule I mentioned was a reaction to the bad old days of when CGI.pm in core acted as a drag on adoption of better CPAN-based alternatives. And it was added to core because it had won the market. We should, at the least, not go back to that way of doing things without awareness of how we got where we are. Esp. given how costly it is to our downstreams when we realise we need to course-correct.Thread Previous | Thread Next