On Wed, Oct 12, 2016 at 01:30:59PM +0100, David Cantrell wrote:
> On Tue, Oct 11, 2016 at 07:27:03PM +0200, Peter Rabbitson wrote:
> > Words are cheap. Let's look at the record instead: In the past several
> > years mst has been directly responsible ( single-handedly or in part )
> > for the following:
> > - Shoving FATAL-ized warnings down CPAN's users throats. After years of
> > incessant pushback finally semi-relented, but still continues to
> > insert it into his CPAN projects to this day.
> This is not necessarily a bad thing.
> In fact I've done it myself. First I deprecated a feature in the
> documentation. Then a while later I made it emit a warning. Then another
> while later I got rid of it which, if people were still using the
> deprecated feature, made their code die. Getting rid of the deprecated
> features made the code simpler and easier to understand, and so less
> likely to be a bug-laden piece of crap.
In this case, riba's referring to 'use warnings FATAL => ...;', or these
days the specific subet of warnings that 'use strictures 2;' fatalises.
Which is very much a trade-offs situation - I want e.g. an unexpected undef
to cause my code to die(), because 'unexpected' means 'this might be a bug',
and I'd prefer a crash to completing in an unexpected state and risking
I'm also happy to have code that dies on newer perl versions that didn't
previously until patched, because the last time a newly added warning caused
that to happen to a piece of my code, that also exposed a bug.
I'm very conscious of the potential additional inconvenience to users as a
result of this approach, but prefer inconvenience of the form of an
unexpected crash over the increased risk of the code completing successfully
from the POV of the surrounding application while having actually done the
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue
Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.
Searchable Archive: http://email@example.com