Bug #93004 for Moo: Default fatalization of warnings needs mst's clarification before new major strictures

I won't speak for haarg. I do however feel the need to correct you here, ribasushi. The reason why i talk about this matter is not that i think that "non-fatal uninitialized are not an option". The reason is that i do not understand why fatal undefs are not an option for some people. The reason i discuss is to get more information to understand their situation, so that i can empathize with them. Simply and bluntly put, any explanation given i have seen so far, boils down to a combination of these points: 1. they believe undefs cannot possibly do any harm 2. they do not wish to test their code 3. they do not wish to write code that expects actions to break and handles breakages I do not personally believe that the people who claim this actually have only these reasons, but i cannot think of further reasons, so i talk to try and understand them better. I'm not saying: You're wrong. I'm saying: Help me understand you.

+1; until a fix we will be locally patching Moo

+1 as well, although this is only one of many issues with Moo, things like the following are also an issue: - the VCS behaviors change in strictures (unacceptable assumption making) - the low quality error messages from type constraint failures (typically an "error at eval line ##" thing) - the inclusion of non-standard Moose features and behavior - the lax constructor (it seems to bless the hash it is given directly, haven't dug too much in this, but on the surface it seemed to be what was happening)

On Thu, Feb 13, 2014 at 10:05:05AM -0500, Stevan Little via RT wrote: Show quoted text
Stevan: So file separate issues for these? If they do not get fixed at least there will be linkable record (with discussion) of why Moo and Moose diverged. Also afaik the error messages were improved lately... a lot. If you don't like something - do your part in at least documenting it ;)

On Thu Feb 13 09:52:27 2014, MITHALDU wrote: Show quoted text
1) Not all undefs are harmful, this is a determination that should be made per-codebase and not enforced by a (well meaning) CPAN module. 2) Not all code can be tested with 100% coverage to ensure that no undef's will occur, especially if that code deals with any kind of input from the outside world. 3) See #2, not all breakage sites can easily be identified, captured and dealt with appropriately. See #1, not all breakages are really a "breakage" at that moment, and instead might be dealt with in another layer of the application. As I said in #1, this is a per-codebase determination and not something that should be decided by a CPAN module. The right thing to do is to decouple strictures from Moo, if Moo is truly to be the "Moose for CPAN", then it must shed its more controversial opinions, of which this is one.

On Thu Feb 13 16:09:22 2014, RIBASUSHI wrote: Show quoted text
Let me put things more simply: Please at least make some kind of attempt to not misrepresent me when talking about what i said. I'm fine if you don't want to have the discussion with me, but i get grumbly if you hyperbolize and misinterpret what i said and then use that to further your own points. ------ As for the discussion itself, personally i wouldn't mind at all if strictures was uncoupled from Moo. I find myself declaring my flavor of strictures manually as a matter of taste in all cases anyhow.

For me: Turning FATAL warnings on by default makes sense in a dev environment. It does not make sense in a production web environment. If FATAL warnings are enabled in a production environment then a minor error, like concatenating undef into a string or template, is something that *might* be visible to the user, but it also might not. It certainly wont impact much beyond making the page look less professional than it should. However when that undef causes the page to die, then the user is directly impacted. They either see a 500, or they get redirected to an error handler. One of the principal virtues of Perl is that it doesn't get its knickers in a knot over minor errors. It warns and moves on. Making Perl chuck all its toys out the pram because *maybe* that undef is Really Important, is a decision that should be left to the application designer, not a module author who has no idea of the relative trade offs where it is used. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"

Thank you for being open to discussion about this issue. I agree in principle that warnings in my code need to be addressed and the underlying issues fixed, especially before going into production in most cases. I have to disagree with Moo imposing fatal warnings on my code. It is unnecessary and detrimental for both development and production environments. I want to see warnings during development and testing so I can fix them. I don't want my code to explode from a warning. Fatal warnings are not warnings anymore, they are errors. It's redefining a term that has a clear meaning in the context of software development. Production software is messy. As much as we would like all code we put into production to be clean, elegant, and well-behaved, this doesn't always happen. I might have to postpone cleaning up a warning to a later time. There might be a spurious warning caused by a rare edge case. These should not cause my production application to blow up. The consequences of not using fatal warnings in production is my responsibility. I think Moo is awesome and I'd like to keep using it. But until it stops imposing fatal warnings on my code I will have to use Moose for serious projects. Thanks for listening.

On Thu Feb 13 09:23:50 2014, RIBASUSHI wrote: Show quoted text
On consideration, it seems to me that the playing field has changed sufficiently that a chance is a good idea. The original motivation was for newbies coming afresh to M* style OO; more and more Moo is -also- being used as "Moose for CPAN" rather than just "Moose for constrained environments", so there are more people coming to it with assumptions based on long-standing usage of Moose. So, given the assumption that newbies always accept the defaults, I think we can probably achieve pretty much the same goal without annoying the crap out of everybody else by explicitly documenting use strictures; use Moo; in the SYNOPSIS, and changing Moo.pm itself to turn on only strict+warnings to bring it back in line with Moose. This *is* going to require a 2.0 label because code written under the assumption of fatal warnings may potentially do highly undesirable things in their absence, but that doesn't mean it necessarily requires that much waiting. I'll put out a blog post at some point soon trying to work out if there's anything else we'll want to change/break.

Small update on the matter, the code and doc update, done earlier by dams, is good to go: https://github.com/moose/Moo/pull/3/files This leaves mostly the meta tasks mentioned by mst.

On 01/29/2015 06:18 PM, Peter Rabbitson wrote: Show quoted text
While agonizing over how to properly word the last update I *completely* missed commit 301f1e89db7 [1] that took place less than a day ago, and which addresses all the technical issues I raise above. At this point I do not see a blocker for Moo 2.0: as it stands under default conditions the code addresses both the undefined behavior in FATAL corner cases, and the optree mangling due to indirect/multidimensiona/bareword::filehandles. The opt-in mechanism is elegant and unobtrusive. The documentation still recommends use of FATALs, but this battle is in the hands of p5p at this point [2]. Apologies for the noise and the ill-timing of the previous email. Unless someone else has objections the ticket can be closed. Cheers [1] https://github.com/moose/Moo/commit/301f1e89db7 [2] http://thread.gmane.org/gmane.comp.lang.perl.perl5.porters/146265/focus=147472