http://www.perlmonks.org?node_id=864040


in reply to Writing a better Modern::Perl

I fully agree with JavaFan about having to remember (and let's not forget, also having to install) various new policy modules - they don't seem to be worth the trouble for me.

A few minor nits:

IMHO 'nextgen' (and also 'Modern' in Modern::Perl) is a bad toplevel namespace; a Policy:: or policy:: namespace would fit better. Hubris is supposed to be a virtue for Perl programmers, but only while writing code, not while interacting with the rest of the world.

autodie (will be core in 5.12 anyway)

That sounds as if 5.12 were the future. It's not, it's been released almost half a year ago. That said, autodie was also included in 5.10.1

Another thing to mention is that loading utf8 does more harm than good, unless you also set up decoding and encoding IO layers for input and output.

Perl 6 - links to (nearly) everything that is Perl 6.

Replies are listed 'Best First'.
Re^2: Writing a better Modern::Perl
by EvanCarroll (Chaplain) on Oct 07, 2010 at 17:14 UTC

    Fixed on autodie reference, I was using it before 5.10 and that was my oversight. Glad to know it is in core now, and has been for a while!

    As, for utf8, I wholly disagree, the encoding of the perl source and of the IO stream should be separate. You can argue that both should be UTF8: but, I don't think you can logically argue that the Perl source shouldn't be utf8. Even if you're not using UTF8, and even if the files you want to read aren't using utf8, the authors using nextgen and contributing to CPAN should be encoding their perl source in UTF8. We shouldn't assume they have the same legacy-needs you do.



    Evan Carroll
    The most respected person in the whole perl community.
    www.evancarroll.com
      but, I don't think you can logically argue that the Perl source shouldn't be utf8.

      That's not at all what I'm arguing.

      I simply made the experience that concatenating binary strings and decoded strings lead to nasty errors. So if you don't bother to decode strings on input, telling Perl that the source file is UTF-8 is harmful.

      If your script or module is written in UTF-8, input and output data is UTF-8, but you don't decode or encode, everything "works" in the sense that the output is correct UTF-8 (though of course the strings don't follow proper Unicode semantics internally). In this case use utf8; leads to incorrect output.

      Perl 6 - links to (nearly) everything that is Perl 6.