Re^2: RFC: Devel::Deprecate

I thought about an update system, but realized that I'd be introducing a complication that might not be appropriate. Going with dragonchild's recommendation of making the 'if' key point to a subroutine and you could hook in anything you wanted. Suggestions still welcome, though.

I think possibly that if we hit the 'die' date, maybe it should warn if the condition is not triggered. That way developers would know to remove the code or update their dates.

Cheers,
Ovid

New address of my CGI Course.

Comment on Re^2: RFC: Devel::Deprecate

Replies are listed 'Best First'.
Re^3: RFC: Devel::Deprecate by mr_mischief (Monsignor) on Apr 23, 2008 at 18:04 UTC
Well, I'm not sure how to name them, but if you had an unlimited number of dates and each date could be assigned its own sub, you could make it extremely flexible. Perhaps an unlimited number, but with certain names reserved would work. `phased_update( { intro => [ "2008.06.01", sub {} ], # not reserved foo => [ "2008.08.01", sub {} ], # not reserved deprecate => [ "2008.12.31", sub {} ], # reserved dead => [ "2010.01.01", sub {} ], # reserved } );` [download] The exact syntax might need some work, but you get the idea. The reserved values could trigger default actions if there's no sub.	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: RFC: Devel::Deprecate
by mr_mischief (Monsignor) on Apr 23, 2008 at 18:04 UTC

phased_update(
  {
    intro => [ "2008.06.01", sub {} ], # not reserved
    foo   => [ "2008.08.01", sub {} ], # not reserved
    deprecate => [ "2008.12.31", sub {} ], # reserved 
    dead => [ "2010.01.01", sub {} ], # reserved
  }
);
[download]

The exact syntax might need some work, but you get the idea. The reserved values could trigger default actions if there's no sub.

[reply]
[d/l]