Front page | perl.perl5.porters |
Postings from July 2011
On Mon, Jun 13, 2011 at 05:15:42PM -0400, David Golden wrote:
>
> So here are some of my initial thoughts on criteria:
>
> (1) Is the addition likely to be a commonly used feature by the
> "average" programmer? If so, more appropriate for core.
>
> (2) Is the addition something for which there is only one correct
> answer or one way to do it? if so, more appropriate for core. To me,
> that means that anything with more than one or two arguments/operands
> or that could return different things depending on context could have
> some debate over the right API and is less appropriate for core.
> File::Slurp and read_file is a great example. I'd love a core "slurp"
> but File::Slurp shows the many variations (for good reason) that make
> it tricky to know the right defaults.
>
> (3) Is it necessary for correctly implementing some algorithm or
> technique? If so, more appropriate. E.g. Scalar::Util and weaken()
> come to mind
>
> (4) Does it simplify some frequently misused technique or make a
> common bug less likely? If so, more appropriate. E.g. Try::Tiny or
> Scalar::Util::blessed() come to mind, as does the new s///r syntax.
>
> What do people think of those? What other criteria would you consider?
Ownership.
Once a module is on CPAN, you're at the mercy of a single person to
apply patches. If the owner loses interest, or doesn't have time, it
may very well be a module no longer is going to work on a new release
of Perl, or that important bugs just don't get fixed. If a module is
in core, then at least there are multiple people who can apply a patch.
My guess is that there's less chance of a module suffering "bitrot" when
it's in core than when it's on CPAN. [1]
OTOH, a module on CPAN with an active owner can have more frequent release
and bug fixes than a module in core.
[1] Yes, there's always the possibility of a fork, but that's a major
hurdle. People don't like forks, and it will require a name chance.
Abigail
Thread Previous
|
Thread Next