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.
  • by reezer (9663) on 2010.04.08 4:52 (#71851)
    Sorry, if the following text sounds a bit rude ;-) I don't really know what the big problem is. At the beginning you wrote you test it in a way beginners would do, meaning you don't want the modules to cause problems to beginners. Enabling use strict and use warnings is definatly the way to go in more than 99% of cases. Even Perl6 enables it per default. Nearly every module forces you to something and these two things shouldn't really be a problen in most cases. Even low level programming languages (meaning compilers) complain about a lot of things if you don'ttry to get around them. If you really want to leave the best practice path, why not set no strict/warnings? It's not a really big problem and with a good editor/ide this can be automated. I agree that both ways have their advantages and disadventages, but it doesn't seem like a big deal to me, but that's just my opinion.
    • There's several problems:

      One, the module is doing something that isn't its advertised function and _really_ isn't neccessary to implement its core function.

      Two, it's changing behaviour of the parent program, this is a bad thing to do even when it _is_ neccessary.

      Three, it isn't clear in situations like the Moose one, just when to turn it off or on, consider the following sequence within a single scope:

      You enable warnings/strict. You do some code. You turn off warnings/strict. You do some code. You use M