# Life Phases of a Ruby Method **URL:** \ **Category:** Ruby\ **Created:** [September 5, 2010, 11:06pm UTC](https://www.ruby-forum.com/t/life-phases-of-a-ruby-method/194432 "2010-09-05T23:06:13Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![reverri](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/13edae/32.png) [@reverri](https://www.ruby-forum.com/u/reverri)\ **Post date:** [September 5, 2010, 11:06pm UTC](https://www.ruby-forum.com/t/life-phases-of-a-ruby-method/194432/1 "2010-09-05T23:06:13Z")
The following is _my_ idea of the phases that a Ruby method could go thru in it’s “lifetime.” (I’m generally applying this to Ruby Application APIs, not the MRI Core, but may work for the Core as well.) A method would _not_ need to go thru all phases I show below. * * * Life Phases of a Ruby Method: (1) Immature [_] A method that has been created, but has yet to “mature” and enter the workforce. [_] The method is intended to become a “Working” method, but must survive the development stage, be released, and then pass into general working use. [_] If the method does not work, and is not fixable, it may never be classified as “Working.” [_] An immature method that never operates correctly, could at sometime, be reclassified as either “Retired” or “Deceased,” skipping several phases. (2) Working [_] A mature, working method, that is in the “method workforce” of the module or class. [_]It could contain a minor bug, but still be usable. (3) Deprecated [_] A method that is not recommended for new programs, but still exists. [_] It may have a replacement method that should be used in it’s place. [_] Calling it, may issue a “Deprecated” Warning to $stderr when called, if $VERBOSE == true. [_] The warning should inform coders as to the name of the replacement method, and/or the reason it has been deprecated. [_] For backward compatibility, the method should still function, during the deprecated “grace period,” giving developers time to migrate their code to using the new method. [_] A module or class definition can contain an array Constant of “Deprecated” method names, that can be queried. (4) Retired [_] A method that is not allowed to be used, and is overriden to automatically call a replacement method. [_] Calling it, should issue a “Retired” Warning to $stderr when called, if $VERBOSE != nil. [_] The warning should inform coders that the method called is “Retired”, and that the replacement method was called in it’s place. [_] The warning may also seek to persude the programmer to update their code, before the method becomes deceased (after the “grace period” ends.) [\*] A module or class definition can contain an array Constant of “Retired” method names, that can be queried. (5) Deceased [_] A method that has been removed from the code and no longer exists [_] Calling the method, results in Ruby calling method\_missing, which has the default behaviour of raising a NoMethodError exception. [_] A module or class definition can contain an array Constant of “Deceased” method names, that can be queried. [_] The module or class definition’s method\_missing method, can be overriden to check the array of deceased method names, and modify the standard error message that is output by the NoMethodError exception, like: Error: #\ * * * Does it sound like I’m on the right track here ? Would it be better to use Hashes to hold info about Deprecated, Retired and Deceased methods, ie: key is method name, value is array data [date, version, grace period] ?? Any flaws in my logic ?? ---
**Author:** ![reverri](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/13edae/32.png) [@reverri](https://www.ruby-forum.com/u/reverri)\ **Post date:** [September 6, 2010, 4:39pm UTC](https://www.ruby-forum.com/t/life-phases-of-a-ruby-method/194432/2 "2010-09-06T16:39:34Z")
On Sep 5, 2010, at 14:06 , Dan R. wrote: > (1) Immature What’s the point of this phase, at least as far as mapping out lifecycles of code? Deprecated/Retired/Deceased makes sense to me (with reservations below) to have an organization formalize their API support lifecycle… Beyond that, I don’t see the point. > (3) Deprecated > [_] A method that is not recommended for new programs, but still > exists. > [_] It may have a replacement method that should be used in it’s > place. > [_] Calling it, may issue a “Deprecated” Warning to $stderr when > called, if $VERBOSE == true. > [_] The warning should inform coders as to the name of the replacement > method, and/or the reason it has been deprecated. > [_] For backward compatibility, the method should still function, > during the deprecated “grace period,” giving developers time to migrate > their code to using the new method. > [_] A module or class definition can contain an array Constant of > “Deprecated” method names, that can be queried. > > (4) Retired > [_] A method that is not allowed to be used, and is overriden to > automatically call a replacement method. > [_] Calling it, should issue a “Retired” Warning to $stderr when > called, if $VERBOSE != nil. > [_] The warning should inform coders that the method called is > “Retired”, and that the replacement method was called in it’s place. > [_] The warning may also seek to persude the programmer to update > their code, before the method becomes deceased (after the “grace period” > ends.) > [\*] A module or class definition can contain an array Constant of > “Retired” method names, that can be queried. Why differentiate between the two? Saying “is not allowed to be used” but then you allow it and do the right thing for the user doesn’t make sense to me. I think in almost all my cases, I’d rather go from Deprecated (but with the warning semantics of Retired) to Deceased and not bother with the Retired step that doesn’t make sense to me. Additionally, not all retired code will properly map to the new API as-is… further complicating the matter.