Front page | perl.perl5.porters |
Postings from December 2010
On 13 December 2010 17:33, Zefram <zefram@fysh.org> wrote: > Given that (a) there are already multiple versions of this on CPAN, > (b) there are competing versions of the semantics, and (c) it's easy > to implement a new version on CPAN where the existing versions don't > provide the desired semantics, it seems to me that the right place for > this isn't the core, it's CPAN. Personally I think that Scalar::Util, Data::Alias and friends taught us the lesson that the above are poor justifications to argue that something should be on CPAN or be part of core. The reasons I see for putting it in core are: a) it needs XS to be implemented, b) the XS would be maintained by the core dev team, c) by putting it in core we guarantee to our users that a very useful feature will always be available in perls following it, d) it replaces an extremely awkward recipe that involves a module (Scalar::Util) that after much debate and gnashing of teeth pretty much all agreed should have been in core in the first place - repeating such an error with a replacement for one of Scalar::Utils routines seems most illogical. With a CPAN module there is no contract between Perl and the community that something will be reliably available. A CPAN module on the other may fall out of sync with perl and be abandoned by its author or otherwise go unsupported. We have seen this with Data::Alias. We have also seen that in many environments it is anywhere from nearly impossible to quite difficult to get non-standard modules installed at all, let alone ones that require compiling XS code. We have seen both of these problems with Scalar::Util. (I have personal experience of this one.) This is a language feature that allows us to do something that is definitely non-trivial, useful, and likely to be widely adopted. It should BE part of the language, not a nice-to-have after market bolt-on. cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next