In the recent thread on use feature Mark Jason Dominus made a comment that I think is worth analysing in more detail, and frankly deserves a bit of a rant. Its not really aimed at him as the view he espouses is not uncommon in the p5p development world. The analysis is first, and the rant follows, seperated by a divider line. On 3/1/07, Mark Jason Dominus <mjd@plover.com> wrote: > > > It would be nice if 'use feature;' (without an argument list) includes all > > features, just as 'use warnings;' turns on all warnings. But this might > > have already been proposed and dismissed. > > It's a bad idea, because any program with that declaration will break > the next time an incompatible feature is added. > > Consider "use 'strict'". People are allowed to put just "use > 'strict'" in their programs, without saying which strictures they > actually want, and the outcome is that we can't add any new > strictures, because doing so would break every program in the world > that starts with "use 'strict'". I think this argument is flawed. Use strict is supposed to catch constructs that are most likely errors. If we introduce a new stricture presumably we will only do so because we have identified something that is likely to be used incorrectly and therefore result in buggy code. Once we introduce it the only code that will break is the code that does the thing that is likely to be incorrect. And since it is likely to be incorrect the odds are that the new stricture will bring potentially buggy code to the attention of the author. I can't see how this is a bad thing, nor how it would result in breaking every program that uses strict, and in fact id go so far as to say that the programmer has already explicitly asked us to do this type of checking by using strict in the first place. Consider a variant of this issue, if strictures had a bug in it such that something that it catches, lets say symbolic references, wasn't being caught in a particular situation. If we applied the argument outlined above we wouldnt be able to fix this problem because it could break code. ---begin-rant--- Looking at it in a general sense, if you want to 100% backwards compatibility, then DONT UPGRADE. By changing major versions *something* will change, and it could affect your code. But its not going to magically happen underneath them. We can't handcuff sensible behaviour for evermore simply because those that came before us didnt have the foresight to predict everything under the sun. Perl takes a *very* conservative approach towards stuff like that, which is good, but taking it so far that nothing can be changed or improved or extended or fixed is ridiculous. I think its generally understood that people dont upgrade their perls anywhere near as often as we on p5p might wish. So its even less of an issue. Bad code is most likely going to stay running on the perl it was written for. use feature is a bit of a tricky case as it includes something that we KNOW will break a lot of code in the interest of /forward/ compatibility (with the soon to be release Perl 6), and some things that will break various email signature oneliners and obfus. The rest probably wont break much. And if it does well, the people upgrading should catch it in /their/ regression suites before they put the new version into production. I think the real issue here is that we have almost obsessive desire to avoid backwards compatibility issues. A desire that i dont think is healthy, and one that is probably not justified. Its one thing to break old behaviour by accident, its another to do it with conscious decision and document it and warn about it to upgraders. This is not to say that we should break things willy nilly, we shouldnt, taking a conservative approach is good, but we shouldnt assume that avoiding breakage in a small number of modules is the primary concern. That way lays stagnation. An email sig from Jarkko says it all I think: # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen Cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next