Life Phases of a Ruby Method

Discussion in 'Ruby' started by Dan Rathbun, Sep 5, 2010.

  1. Dan Rathbun

    Dan Rathbun Guest

    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/.
    Dan Rathbun, Sep 5, 2010
    #1
    1. Advertising

  2. Dan Rathbun

    Ryan Davis Guest

    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.
    Ryan Davis, Sep 6, 2010
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    519
  2. Van Jacques

    My post on game of life ruby prog

    Van Jacques, Nov 29, 2003, in forum: Ruby
    Replies:
    0
    Views:
    126
    Van Jacques
    Nov 29, 2003
  3. Van Jacques

    ruby game of life program

    Van Jacques, Nov 29, 2003, in forum: Ruby
    Replies:
    6
    Views:
    160
    Van Jacques
    Dec 2, 2003
  4. Derek Cannon

    Life without Method Overloading?

    Derek Cannon, Apr 19, 2010, in forum: Ruby
    Replies:
    6
    Views:
    109
    Jesús Gabriel y Galán
    Apr 19, 2010
  5. Ivo

    Phases of the earth

    Ivo, Jul 6, 2006, in forum: Javascript
    Replies:
    4
    Views:
    122
    Jeremy
    Jul 7, 2006
Loading...

Share This Page