Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Ruby (http://www.velocityreviews.com/forums/f66-ruby.html)
-   -   Life Phases of a Ruby Method (http://www.velocityreviews.com/forums/t864290-life-phases-of-a-ruby-method.html)

Dan Rathbun 09-05-2010 09:06 PM

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 ??
--
Posted via http://www.ruby-forum.com/.


Ryan Davis 09-06-2010 01:23 AM

Re: Life Phases of a Ruby Method
 

On Sep 5, 2010, at 14:06 , Dan Rathbun 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 =3D=3D 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.
>=20
> (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 !=3D 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.




All times are GMT. The time now is 05:31 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.