On Tue, 04 Apr 2006 16:20:09 +0200, David Landgren <[EMAIL PROTECTED]> wrote:
> demerphq wrote: > > On 4/4/06, Sébastien Aperghis-Tramoni <[EMAIL PROTECTED]> wrote: > >> (*) Yes, I know that the core Perl distribution includes many modules, > >> but ask any P5Porter and he'll answer you that the core is over-crowed > >> and that all core modules that can be made dual-life should be released > >> on the CPAN. > > > > I dont agree with this. Or rather, I dont agree that the core is > > over-crowded. I do agree that as many modules should be dual-lifed as > > possible however, but that is just so you can upgrade without > > upgrading perl. > > There are some crappy modules in the core, though. I mean, look at > C<Search::Dict>. Never heard of it :) > I'm never likely to use that in a million years. (partly because the > documentation doesn't help me understand what it buys me). > > Or C<Text::Soundex>. I know what it does, but its purpose is so > specialised (and in this international age, woefully parochial) that it > hardly deserves core status. It's just that it's been in there forever. > In another universe it would be on CPAN only. Possibly with some sort of > plug-in architecture to let you switch in Metaphone and other > algorithms. Then it might be a bit more useful. I *do* use Text::Soundex, and Text::Metaphone together to find user typoes in databases, but I wouldn't mind if the first was not in CORE. But I have never used CGI before, and have no plans to do so in the future, and would not cry if it were taken out. But there is this policy that once a module is in core, it is very unlikely that it will be removed. A very good candidate for removal would be Switch, as it causes more pain than pleasure. > There are also some mistakes, like Switch, but once a module goes in, it > can never be removed. That's the main reason why people are so leery > these days of adding new stuff to the core, in case they get it wrong. As I said. I fully agree. > > Personally i think the "core is too big" argument is a red-herring > > given that bandwidth is as cheap as it is these days. Adding a couple > > I don't think bandwidth is the argument. > > > of modules to core would increase the rsynch time by what a second or > > two? It would suck up a couple of extra K, something like 1% of what > > most of use for our web-browser cache. So the size argument IMO doesnt > > hold water. > > There is the multiplier effect of having that new K stored on all the > mirrors to keep in mind. > > > Also, there is a tension in the community relating to this issue that > > i dont think we will see any resolution of soon. > > > > Many module authors set a design objective of making their modules > > "dependent only on core modules". This is a comment that I see on a > > regular basis. And then still people make more of the same. Take Getopt::Long. A perfect and very functional module. Full of features, matured, and actively maintained. Now go look at CPAN, and see how many people either do not like it or find other reasons to write their own. The problems arise when authors of big modules start prefering non-core versions of good core modules. IMHO something like that should give you a (very) negative score on CPANTS. > As long as the core modules are there on the basis that they serve as > building blocks to build other modules, I don't see any problem with > that. The trouble is that all the cool tools are evolving so rapidly > that putting them into core would really cramp their style. > > > IMO this objecitve is in direct contradiction of the purported P5P > > objective of not adding stuff to the core and just makes omissions > > from the core even more critical. > > I'm curious, what's critically lacking? > > > Anyway, i just wanted to add this because I dont think that you can > > take it for granted that all perl5porters believe the core module set > > should be as restricted as possible. I dont. I believe that the core > > should contain out of the box enough support for the various platforms > > that perl runs on that when people write code based only on core > > modules they can do a good job without reinventing wheels or code > > duplication. > > What wheels are being reinvented, or what code is being duplicated? I > think the core problem-space isn't too bad. > > I'm not sure that there are many intermediate level modules left out > there that can be applied to generic module development. I'm not sure > that I want to drink the Class::* kool-aid. > > > Long term i think the community needs to sort out this problem because > > I dont think there is consensus on it, and I think that a lot of > > people only look at the issue from their own individual point of view. > > If somebody is concerned about the overall quality of perl and CPAN I > > think a more holisitic point of view is required. > > Who was it who was working on the global CPAN dependency graph, to > figure out what module was dependent on what? Whatever became of that? I > think hard numbers that stand on their own merits are about the only way > to get new stuff into core. Let the early adopters try out non-CPAN > low-level modules. Then after a while, see what floats to the top. -- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using & porting perl 5.6.2, 5.8.x, 5.9.x on HP-UX 10.20, 11.00, 11.11, & 11.23, SuSE 10.0, AIX 4.3 & 5.2, and Cygwin. http://qa.perl.org http://mirrors.develooper.com/hpux/ http://www.test-smoke.org http://www.goldmark.org/jeff/stupid-disclaimers/
