Front page | perl.perl5.porters |
Postings from January 2012
On 01/30/2012 03:21 AM, David Golden wrote: > Jesse's vision included the notion that changes should happen > lexically under in a declared version block, whenever possible. So in > this case, perhaps the deprecation warning should only occur under > "use v5.16"? Frankly, I think the lexical version declarations are > going to be horribly confusing and I question whether that's the right > path forward or whether a simpler policy change would be more > user-friendly. It seems to me like deprecation warnings should be lexical in a "use 5.future" enabled block IF the deprecated feature is only removed in "explicit 5.future enabled" code and continues to be supported indefinitely in older versions (whether explicit or implicit). Otherwise, we may as well remove the deprecated feature (after deprecation) entirely as barely anybody can tolerate deprecation warnings. > Right now, perlpolicy defines "deprecated" and says that deprecated > features will warn. I wonder if it would be better to introduce a new > category, "scheduled for deprecation", which would be public notice of > future deprecation for one stable release cycle, after which the > feature would be "deprecated" (and begin warning), after which the > feature would be "removed". This three-stage removal process would > give an extra period of notice before code behavior changes. (I still > expect few to pay attention until code warns, but at least we'd be > able to tell them they had notice*.) This may be a good idea and/or necessary for some deprecations. I wonder whether we could combine this extended deprecation scheme with occasionally jumping the gun to skip the "scheduled" stage without causing massive confusion. --SteffenThread Previous | Thread Next