Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • You can't avoid back-compatibility. You just can't.

    CPAN is so central to the success of Perl 5 that even Perl 6 won't break back-compatibility.

    So let's forget about that right now.

    Large changes are also very tricky.

    There's some small things we can do, in fact we've been experimenting with them in the JSAN implementation.

    Things like:

    - Multiple Indexes

    - Mirror Validation and HTTP-centric rather than FTP-centric transport

    There's also plans from the Win32 side of things like a GUI failure-reporting CPAN client.
    • You can't avoid back-compatibility. You just can't.

      Well, the incompatible syntax of Perl 6 will be doing that anyway. The fact is, there will eventually be code on the CPAN that perl 5 cannot run.* If we do it very carefully, we can use this opportunity to do some really nice things for those Perl 6 modules.

      But apart from things currently being brokenish (which we can blame more on CPANPLUS, Module::Build and Module::Install)

      Wouldn't it be nice to have an infrastructure where we could have all those without brokenishness? Part of it is submitting patches to those projects. Part of it may be thinking carefully about how everything is structured.

      * Even with v6.pm, (which is another awesome project), I don't see how you could wrap all the P6 code so that it would look like P5 + v6.pm to perl 5. I could be wrong.