sketchucation logo sketchucation
    • Login
    Oops, your profile's looking a bit empty! To help us tailor your experience, please fill in key details like your SketchUp version, skill level, operating system, and more. Update and save your info on your profile page today!
    ⚠️ Important | Libfredo 15.6b introduces important bugfixes for Fredo's Extensions Update

    Life Phases of a Ruby Method

    Scheduled Pinned Locked Moved Developers' Forum
    1 Posts 1 Posters 258 Views 1 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Dan RathbunD Offline
      Dan Rathbun
      last edited by


      The following is my idea of the phases that a Ruby method could go thru in it's "lifetime."
      A method would not need to go thru all phases I show below.
      Does it sound like I'm on the right track here ?



      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>


      I'm not here much anymore.

      1 Reply Last reply Reply Quote 0
      • 1 / 1
      • First post
        Last post
      Buy SketchPlus
      Buy SUbD
      Buy WrapR
      Buy eBook
      Buy Modelur
      Buy Vertex Tools
      Buy SketchCuisine
      Buy FormFonts

      Advertisement