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>. 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.
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.
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.
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.
David
--
"It's overkill of course, but you can never have too much overkill."
