The Artima Developer Community
Sponsored Link

Ruby Buzz Forum
I Don't want to be an Amphibious Programmer

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Trans Onoma

Posts: 63
Nickname: transfire
Registered: Aug, 2005

Trans Onoma has programming for too long.
I Don't want to be an Amphibious Programmer Posted: Sep 2, 2005 7:29 AM
Reply to this message Reply

This post originated from an RSS feed registered with Ruby Buzz by Trans Onoma.
Original Post: I Don't want to be an Amphibious Programmer
Feed Title: TRANSONOMA
Feed URL: http://feeds.feedburner.com/transonoma
Feed Description: A Light Green Agile Programming and SciTech Blog
Latest Ruby Buzz Posts
Latest Ruby Buzz Posts by Trans Onoma
Latest Posts From TRANSONOMA

Advertisement

I have finally come to the conclusion that the non-localality of instance variables, independent of attribute methods, is not good. Under worse case scenarios, it can lead to amphibious programming -- class diving to find culprit IVs. What's the problem? On the surface, it's that Rubyists treat instance variables as if they were local to the class or module in which they are defined. And while we all know they are not, consider how often you have seen documentation that lists all of a classes/modules instance variables? Probably never, since we can't look to RDoc for help. And since instance variables are autoviviable, there's really no way for RDoc to even completely do so. It's unfortunate. But what can we do? The fact is Ruby makes it seem okay.

Now, maybe you're wondering what the problem is exactly, and, if it is indeed such a problem, why hasn't it biten you before. Well, consider the following.

  class Amphibian
    def initialize( amphibian_type )
      @type = amphibian_type
    end
    def amphibian_type ; @type ; end
    def hop
      puts "And the #{amphibian_type} hops!"
    end
  end

  class Toad < Amphibian
    attr_reader :type
    def initialize
      super( 'Toad' )
      @type = 'dry'
    end
    def hop
      puts "And the #{type} #{amphibian_type} hops!"
    end
  end

  class Frog < Amphibian
    attr_reader :type
    def initialize
      super( 'Frog' )
      @type = 'slimmy'
    end
    def hop
      puts "And the #{type} #{amphibian_type} hops!"
    end
  end

  Toad.new.hop
  Frog.new.hop

produces

  And the dry dry hops!
  And the slimmy slimmy hops!

These things should not be hopping! Obviously, we got the wrong hoppers b/c our Frog and Toad programmer did not know our "aqua team" programmer used the @type instance variable. And therein lies the clue as to why this doesn't often "bite". Ruby has a convention of naming attributes the same as its instance variables. A convention pushed by the use of the convenience methods attr, attr_reader, attr_writer and attr_accessor. So, more often then not #type gets @type and #type= sets @type. This convention (combined with the simple fact that there are a many a words to choose from) greatly reduces the likelihood of instance variable name clash. Of course, some might claim this to be a feature. We can easily share instance variables between classes and subclasses, and, thanks to the convention, generally not have to worry about banging into each other. Well, maybe. While it usually worksout, its not something with which a critical applications developer tends to feel terribly comfortable, esspecially when deploying to a live scenario. And, yes, I realize, some of you will point out test-first development. Sure, that can help, but that's not a good excuse. You can use that argument to justify goto and using only global variables. In the end, it's not really a feature at all, and leads to less stable code.

In a future entry, I'll consider potential remedies.

Read: I Don't want to be an Amphibious Programmer

Topic: Announcing the MouseHole Proxy Previous Topic   Next Topic Topic: RubyConf[:2005] > (RubyConf[:2004] * 2)

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use