Don’t @me, or Maybe Do? – The Lifespan of Instance Variables in Ruby

What’s the purpose of @ and attribute accessors in Ruby? The key concept here is survival. Ok, that sounds a little dramatic, but access to and longevity of an instance variable or its attributes is crucial if we want to access and manipulate them outside of their native block of code.

Take the creation of a coffee class that takes the attributes of size and type defined as follows,

class Coffee
       def initialize(size, type)
end
coffee = Coffee.new(:medium, :cappuccino)
puts coffee

That at least tells us there’s a card there, but, it hasn’t stored the rank and the suit values. You might be thinking, “cool, well, I can just grab one of those attributes with the following code”,

puts coffee.size
But remember, survival.

Outside that “end” block, those attributes can’t be stored or accessed. That’s where you need to @them. Even if it’s not your style.

So,

class Coffee
      def initialize(size, type)
               @type = type
               @size = size
end
coffee = Coffee.new(:medium, :cappuccino)
puts coffee.type
Now the attributes can be stored in memory. These are called “instance variables” and they survive as long as the card is around. But, we still need to access those attributes outside the block of code. One way of doing this is to create a method for each,

class Coffee
      def initialize(size, type)
              @type = type
              @size = size
      end
       def size
           @size
       end
       def type
          @type
       end
end
coffee = Coffee.new(:medium, :cappucino)
puts coffee.type

Try it out in the terminal with your own class and attributes. We survived! What more is there? Well, shorthand survival. Because, ain’t nobody got time for that.
In Ruby using an attribute reader, attr_reader, will do exactly the same thing as above, allow you to access and output the method.

class Coffee
      attr_reader :size, :type
      def initialize(size, type)
             @size = size
             @type=type           
      end

coffee = Coffee.new(:medium, :cappuccino)
puts coffee.type
puts coffee.size
end
It works! It won’t, however, allow you to manipulate or change it. That’s what the attr_writer is for.

class Coffee
         attr_reader :size, :type
         attr_writer :size, :type
         def initialize(size, type)
            @size = size
            @type=type           
         end

coffee = Coffee.new(:medium, :cappuccino)
coffee.type =  ‘latte’
puts coffee.type
puts coffee.size
end
And, even shorter again, attr_accessor, because we’re probably going to use both, right?

class Coffee
       attr_accessor :size, :type
       def initialize(size, type)
             @size = size
             @type=type           
       end
coffee = Coffee.new(:medium, :cappuccino)
coffee.type =  ‘latte’
puts coffee.type
puts coffee.size
end

Finally, rather than just calling the attributes, we can add an output method that will output the coffee itself.

class Coffee
       attr_accessor :size, :type
       def initialize(size, type)
             @size = size
             @type=type           
       end

       def output_coffee
             puts “A #{@size} sized #{@type}”
       end

coffee = Coffee.new(:medium, :cappuccino)
coffee.type =  ‘latte’
coffee.output_coffee

end

And you should be left with a “medium sized latte”. Yum.


So, did you survive?

Categories Collide: Logic Meets Creativity

 One of the main themes of my doctoral thesis in linguistics is the notion that “to cognize is to categorize”. As humans, we have a tendency to identify, evaluate and categorize. And that’s a good thing. Categorizing the edge of a cliff as “Dangerous!” or putting our hand in the fire as “bad idea” is helpful and probably wise. If we meet a stranger and pick up in the cadences of a French accent, we might attempt a friendly, “Bonjour!”. However, our natural ability to categorize is sometimes skewed, and, in the absence of nuanced insights, downright harmful at times. What if Alex Honnold looked at the edge of a cliff and it only ever set off the “Danger!” category? Ok, some of you might think that’s actually not a bad idea. But, on the basis of experience, skill and opportunity, that cliff-edge also sets off his “Challenge!” and “Possibility!” categories, resulting in an incredible human feat that drops jaws in wonder and sets a few palms sweating (trust me, I’ve felt my husband’s).
 So, why do I mention all of this. Well, with an undergrad in psychology and an (almost) PhD in linguistics, I’ve been immersed in the humanities and social sciences to a large extent. And having recently stepped into the realm of programming, I had previously thought that this was a hard-wired world of electrical signals hidden behind screens and immersed in a mysterious cloud that was very much out of my reach. Basically, not my field. Categorization: “Off-limits!”. But, when I realized that coding had a big role to play in the world of linguistics, in natural language processing and machine learning, I was intrigued. And when I wrote my first line of code and saw the words, “Hello World”, pop up, I was hooked.
 Worlds collided, categories meshed together. In linguistic terms, coding versus the humanities suddenly seemed to be more prototypical than classical categories. Basically, the edges were fuzzy. I started to think of the possibilities. I was reminded that I loved logic; black and white, right and wrong, but I also loved beauty, romance, head in the cloud-ness (see, I can even make terrible programming puns now). I quickly saw that at my hands were logical tools that, when used wisely, could create things of great beauty, means by which people can be educated, cultures and languages  can be preserved, and scattered families can communicate.
Categories can be helpful, but sometimes it’s good to have them collapse in on each other and create a beautiful unplanned soup (another coding pun, I’m getting good at this). And as I work on getting this new set of skills under my belt, I’m excited to see where this collision of worlds will take me.