D
Dan Rathbun
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 ??
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 ??