It isn't an argument against nextgen, it is an argument against defaults. Why aren't they your cup of tea? would be the question that would permit me to make nextgen better, unfortunately I didn't ask that. Instead, I brought to light the weak merits of arguing against defaults, and against a method that tried to better them.
And, not respecting one argument does not mean that I do not respect the opinions of others. I respect that he won't use my module because he prefers to replicate boiler plate code through editor macros (for some value of respect), that doesn't mean that the source argument against implicitly doing what you want is a good one, especially for the perl community.
| [reply] |
It isn't an argument against nextgen, it is an argument against defaults.
Not at all. It was only an argument against modules that change defaults, but don't do anything else. (Which is not a default at all, because you have to do something to enable it. So it's just a policy, not a default).
Perl 6 - links to (nearly) everything that is Perl 6.
| [reply] |
Is perl malloc a policy or a default if I nuke the makefile? I don't even really care if you want to oppose this module because its default is to implement a policy that changes the defaults of Perl by importing other modules which make it a ..... to change Perl's .... of ....: that's your own silly pedantic reasoning. It won't help me make nextgen better, and so I don't really care.
| [reply] |
Why aren't they your cup of tea? would be the question that would permit me to make nextgen better, unfortunately I didn't ask that.
You cannot make nextgen good enough that I would use it. There are only three pragmas/modules I use in the majority of the code I write: 'use 5.010; use strict; use warnings;'. I write diverse code. Any other module will not be used in the majority of the code I write. Of course, you could have 'nextgen' take arguments, for instance, a list of modules to load - but then I may just sidestep it directly, and use them directly.
| [reply] |
Lets ignore Moose for the time being... Why do you chose not to use autodie, or indirect, or namespace::autoclean, or even mro "c3" is it because you don't understand these modules, or that you prefer the behavior without them, or that you just don't care (and should therefore care little if the behavior is changed)?
Update 1:
What is "diverse code"? Does someone who refuses to use strict write "diverse code"? How do you feel you don't need these modules, and for the love of god how can a module make your code less "diverse"? And again what the hell does this have to do with nextgen? So far you've attacked having defaults, and using modules: none of this is specific to my pragma.
Update 2:
I will again argue that the "diverse" nature of code shouldn't change your definition of bad practices: autodie stops silent failures from a standard library (CORE) that should throw fatal exceptions anyway.. Code run inside of Cron, or Mason pages, or modperl should have this policy/default. I don't think your argument has any more or less merit than picking if you want perl 5.12.0 or 5.0 depending on the task: after all they have different runtime profiles because of their internal sorting routines.
| [reply]
[d/l] |
