First off, I stole this pic from Greg Pike’s post about Javascript.  Now that the confession is out of the way…

Today at App Academy my pair and I were asked to explain the meaning of Ruby’s “double pipe equals” operator  to our cohorts.  I figured that might be a good topic to post here.

The double pipe equals, which will be referred to as “||=” from now on, is an operator that’s used for conditional assignment.

In a nutshell the||= operator’s usage is something like this:

blah ||= blabbity_blah()

This essentially says: “if blah is false then set it to blabbity_blah(), otherwise leave it set to whatever it was before we started”

Here’s a contrived, but-still-real-code, example lifted (and modified) from Wikibooks:

Ruby provides 3 ways of classifying a methods in a Class: Public, Private and Protected.  These keywords are used to declare a method’s visibility and essentially what you’re doing is restricting access to the individual methods contained in your class.

Here’s a quick and dirty about the differences:

Public

These methods are accessible by anyone who calls your class.  They define your class’s public “interface”.

Protected

Protected methods are accessible by objects of the same class.  By this definition, a good use case is when classes extend your class and want to access those methods.  The subclass will retain access into the super class’s protected methods.

Private

Private methods can mask the gory details of how the public/protected take input and generate output.  One way to look at this is that these methods are essentially for the “author of the object/class”.  And by “author” I do mean the guy who wrote the code.  Because private methods are not publicly exposed — aka someone who calls your class doesn’t have access to them — private can be considered free for refactoring, changing and deletion without worrying that your outside callers are going to have problems.

Here’s a cool trick for dealing with situations where you want to assign multiple values at the same time.

The technique used is called parallel assignment and it looks something like this:

If you’re working with game boards, this is super useful way to pass around board coordinates!!

If anyone actually reads this, here’s an unusual circumstance to look out for… circular object references that cause Pry to go BSC.

(For those who don’t know, Pry is a Ruby shell that can be used as a replacement for the default Ruby shell, IRB (like IPython for python people).)

Today I witnessed a pretty strange phenomenon where I had a game board that contained a bunch of objects representing items on the board.  Each item involved in the game also contacted a reference back to the game board.  After building this circular awareness we starting having problems with Pry where it would just flat out lock up and tax the CPU like crazy.

After some investigation we narrowed things down to the inspect method and the fact that whenever a statement in pry is executed (and irb too… I think) the inspect method is called on it.  This ultimately gives you the nice visual representation of your objects we all love.

After some investigation and soliciting help from peers it looks like this was probably caused by the fact that the game board object referenced other game objects that in turn referenced the game board…. and so on…

In the past, this has NEVER been a problem for me, and later in the day I wasn’t about to reproduce it with different code… the situation today definitely caused a problem and wasted at least 30 minutes.  🙁