sketchucation logo sketchucation
    • Login
    ℹ️ Licensed Extensions | FredoBatch, ElevationProfile, FredoSketch, LayOps, MatSim and Pic2Shape will require license from Sept 1st More Info

    Life Phases of a Ruby Method

    Scheduled Pinned Locked Moved Developers' Forum
    1 Posts 1 Posters 243 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