Life Phases of a Ruby Method

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: #<NoMethodError: deceased method `do_not_pass_Go’ called for
Monopoly:Module>


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 ??

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.