Beefy Boxes and Bandwidth Generously Provided by pair Networks Cowboy Neal with Hat
Perl Monk, Perl Meditation
 
PerlMonks  

Re: RFC: Devel::Deprecate

by Jenda (Abbot)
on Apr 23, 2008 at 22:25 UTC ( #682509=note: print w/ replies, xml ) Need Help??


in reply to RFC: Devel::Deprecate

I would not want the code that was tested and put to production to start producing warnings or even crashing when not updated by a certain date. For whatever reason the schedule may slip, the new version be postponed and then what? Will you release a quickfix that just changes the dates? And hope you did not forget any or change the computer clock before you run the test to make sure?

If the Devel::Deprecate knows to only make fuss within the test suite, great, if it's a timebomb within production code, no thanks.


Comment on Re: RFC: Devel::Deprecate
Re^2: RFC: Devel::Deprecate
by Your Mother (Canon) on Apr 23, 2008 at 23:33 UTC

    And hope you did not forget any or change the computer clock before you run the test to make sure?... if it's a timebomb within production code, no thanks.

    Extra thanks for my part. The sort of fuzziness on deadlines is no small part of why things slip. I find real deadlines tremendously important in life and one of the easiest ways to tell apart people I want in my life and people I don't. I died a little inside every time someone at university begged, cajoled, or threatened a professor into extending a deadline. Sidenote: Come to think of it, maybe checking a server clock should be a part of any robust deployment and test suite.

    Being realistic, of course you're right, schedules slip. I think there are at least three ways to approach it.

    1. Don't use the "die" argument. If you're in the kind of company that lets millions of error log lines stack up with warnings without caring, what's another 100,000?
    2. Use named environment constants -- like MILESTONE_3_a => '2008-08-02' -- to set the dates so they may be updated at a single point as the project might require.
    3. Use the callback sub ref to allow deprecated code to still run while in the production environment only.

    For the interface it might be nice to be able to have confess, cluck along with die and warn as args... or hooks for your local exception mechanism...?

Re^2: RFC: Devel::Deprecate
by ruoso (Curate) on Apr 24, 2008 at 11:04 UTC

    I think the "timebomb" thing is a bad idea at all. It should *warn* that at some time in the future it won't be available, it can even have a prediction of when that is, but I don't think it makes any sense for a software to have a different API depending on the Date.

    I would suggest, however, to replace the Dates for using version numbers, saying that the method is deprecated since version X, and is expected to be removed by version Y, but no automatic disabling of the method.

    daniel

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://682509]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (14)
As of 2014-04-23 23:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (556 votes), past polls