Grinding Gears

Hello and welcome to another Down the Ruby Mine. I’m Sam, one of the Engineering Interns working at FreeAgent over the Summer and I am here to shed some light on a Ruby language feature. If you’re out of the loop, you may have missed my previous posts which can be found here and here. Today we’ll be diving into the most questionably named Ruby feature out there: splat.

Functions are a developer’s best friend. They allow you to make your code more modular and readable without significant efficiency costs. A common roadblock that developers come up against, is allowing functions to take a variable number of arguments. Fortunately, Ruby provides two useful mechanisms for doing just that.

The * or splat operator converts an array into a list of arguments and vice versa. If we want to feed arguments from an array into a function we can do the following:

def show_arguments(arg1, arg2, arg3)
  puts arg1
  puts arg2
  puts arg3
end

argument_array = ["Arg1", "Arg2", "Arg3"]

show_arguments(*argument_array)
# Arg1
# Arg2
# Arg3

Notice that by using the splat operator we can feed in each element of the array as a separate argument. Splat does not have to be used alone in a function call, it can be used alongside other arguments:

def show_arguments(arg1, arg2, arg3, arg4)
  puts arg1
  puts arg2
  puts arg3
  puts arg4
end

argument_array = ["Arg2", "Arg3"]

show_arguments("Arg1", *argument_array, "Arg4")
# Arg1
# Arg2
# Arg3
# Arg4

Approaching from a different angle, the splat operator can be included in the function declaration. This allows a variable number of arguments to be gathered into an array that is accessible from within the function:

def show_arguments(*arg_array)
  arg_array.each do |arg|
    puts arg
  end
end

show_arguments("Arg1", "Arg2", "Arg3")
# Arg1
# Arg2
# Arg3

argument_array = ["Arg1", "Arg2", "Arg3"]
show_arguments(*argument_array)
# Arg1
# Arg2
# Arg3

Splat works well for positional arguments but does not provide any benefits if your function takes in keyword arguments. Luckily we can use the ** or double splat to resolve this. (Yes, Ruby devs have really thought of everything!)

In the same way that splat allows arrays to be decomposed into arguments, double splat extends this to hashes. Below we can see that a double splat-ed hash can be used on a function that takes in keyword arguments:

def show_arguments(first: "first", second: "second")
  puts first
  puts second
end

show_arguments
# first
# second

argument_hash = {first: "new_first", second: "new_second"}
show_arguments(**argument_hash)
# new_first
# new_second 

Similarly if you add the double splat in the function declaration, keyword arguments are parsed into a dictionary which can be used inside the function:

def show_arguments(**arg_hash)
  arg_hash.each do |key, value|
    puts key
    puts value
  end
end

show_arguments
# 

show_arguments(first: "first_arg", second: "second_arg")
# first
# first_arg
# second
# second_arg

If you really want to impress your friends, you can combine both splat and double splat into what is not-so-commonly-known-as a multi-splat-function. This is useful when you want to receive a variable number of optional positional and keyword arguments:

def show_arguments(main_argument, *additional_positional, **additional_keyword)
  puts main_argument

  additional_positional.each do |positional_arg|
    puts "Positional: #{positional_arg}"
  end

  additional_keyword.each do |keyword_arg_key, keyword_arg_value|
    puts "Keyword: key -- #{keyword_arg_key}, value -- #{keyword_arg_value}"
  end
end

show_arguments("main_arg")
# main_arg

show_arguments("main_arg", first: "first_arg", second: "second_arg")
# main_arg
# Keyword: key -- first, value -- first_arg
# Keyword: key -- second, value -- second_arg


show_arguments("main_arg", "other_arg", first: "first_arg", second: "second_arg")
# main_arg
# Positional: other_arg
# Keyword: key -- first, value -- first_arg
# Keyword: key -- second, value -- second_arg

When calling a function the splat operators can be used to turn an array or hash into a list of arguments. Additionally, they allow a variable number of arguments to be gathered up into an array or dictionary within a function. They are two important tools in any Ruby developer’s toolbox, so go out there and use them without hesitation!

I hope that this trio of Ruby tidbits has sated your thirst for language features. As a software engineering intern at FreeAgent, I have been developing an understanding of Ruby and a multitude of cool Rails features throughout my time here. Everyone has been friendly and helpful, happy to answer questions and provide constructive criticism. One thing that has continually stood out to me during my time at FreeAgent is the constant cross-team communication. As cliché as it sounds working here is like being part of a family, one with technically-literate, modern parents and supportive siblings.

Hello there, my name’s Sam and I’m one of the Summer 2019 Engineering Interns at FreeAgent. As part of my time here I’m writing a series of blog posts on Ruby language features. If you’re a first time Down the Ruby Mine reader then don’t fret, because the posts aren’t dependant on each other. However, if you are interested, you can find the first post here. Today we’ll be exploring the wondrously strange world of Ruby’s logical operators. 

In a language like Java, logical operators are straightforward, uninteresting constructs. They are typically binary operators that take two parameters and return a boolean (true or false value). Below is an example in Java:

boolean this_is_true = true
boolean this_is_false = false

this_is_true && this_is_false
// false

this_is_true || this_is_false
// true

On first inspection Ruby behaves the same way:

this_is_true = true
this_is_false = false

this_is_true && this_is_false
# false

this_is_true || this_is_false
# true

However, the behaviour of the boolean operators change when we move away from true or false values. Ruby groups all objects into two boolean categories: truthy or falsy, using this property to evaluate boolean expressions. Everything in Ruby is considered truthy except nil and false. So in Ruby, 0 is evaluated as true in a boolean expression. What a crazy world we live in!

this_is_true = 5
this_is_also_true = true
this_is_false = nil

this_is_true && this_is_false
# nil

this_is_true || this_is_false
# 5

this_is_true && this_is_also_true
# true

Ruby’s boolean operators behave spookily with non-boolean arguments

Ruby’s boolean operators do not always return boolean values. As shown above, they return the last argument evaluated in the expression. In the case where an expression is short-circuited (it does not need to evaluate the second argument to know the outcome) the first argument is returned. This can be seen in the second example above: when the first argument of a logical OR is true, the resulting expression is always true so the first argument — 5 — is returned. 

Now that you are a master of Ruby’s boolean expressions we can discuss the hip assignment operators ||= and &&=.

||= is a widely loved assignment operator, used to assign an object to a variable if that variable is empty. To be more specific, it checks if the object on the left hand side is falsy and if it is, assigns it the object on the right hand side. Under the hood it is performing the logical OR operation:

a ||= b

# is equivalent to

a = (a || b)

If object a is falsy then it gets assigned b. If a is truthy then it gets assigned itself (doesn’t change)

Thus, it is commonly used for conditionally assigning to a variable when it evaluates to nil. Be reticent though, with great power comes great responsibility. Remember that the other falsy value in Ruby is false. Therefore, this operator also triggers an assignment when the first argument is false.

The &&= gets less love and attention from the community, yet it still performs its operation dutifully:

a &&= b

# is equivalent to

a = (a && b)

If object a is truthy then it gets assigned b. If a is falsy then it gets assigned itself (doesn’t change)

The inverse of ||=, the &&= operator can be used to assign a variable a new object when it already points to an existing (truthy) object. The most common use of &&= is when assigning an object the result of a method call on itself. By using this operator you can ensure that the object will only be reassigned if it existed in the first place. In general, it is less obvious to find applications for the &&= operator but that makes it all the more special when you do!

Congratulations for making it to the end. With your new-found logical knowledge you can ponder some of humanity’s oldest questions that have troubled philosophers for millennia. I’ll be back with another post in a week or so, so you can tell me what answers you’ve found then!

Hey there, my name’s Sam and I am one of four software engineering interns working at FreeAgent over the summer. This is my first time writing in Ruby and I’ve had a great time exploring the language. As developers I believe it’s important to develop a fundamental understanding of the core of a language, even when its supplemented by a feature-rich framework like Rails.

Over the next few weeks I’ll be releasing a series of blog posts exploring an eclectic bunch of language features that I’ve encountered during my time at FreeAgent. The function of these features were not clear to me upon first inspection and I hope that by sharing their inner workings with you, we will all end up closer to enlightenment. Time to take a good ol’ fashioned spelunk into the magical, awe-inspiring depths of Ruby.

One thing I first noticed navigating the FreeAgent codebase was the ubiquitous use of the include statement. When it first caught my eye I froze and a cold feeling permeated my body; the fear of the unknown. However, once I had recovered, I realised it looked similar to constructs in languages I was familiar with. It was reminiscent of the import keyword in Python or Java used to get code from one file into another file – a quick google search confirmed this. Venturing on with renewed courage I soon encountered extend and reeled out of my chair in fright. To prevent further office disruptions, I decided it was time to flesh out these keywords once and for all.

Include and extend are closely related to a third keyword, prepend, which I’ll explain for completeness. All three keywords are used to add functionality from one module into a class or another module. The differences between them lie in the way they interact with the class/module being added to.

Before we go into how they work it’s important to understand Ruby’s class hierarchy. Ruby’s object oriented design results in each class having a list of ancestors that form a hierarchy of inheritance. The top-most ancestor of all objects is the BasicObject class — since Ruby 1.9 — while the bottom-most is (almost always) the class itself. Let’s take a look at the ancestors of the friendly Array class:

If you don’t specify a parent class when creating a class in Ruby, the class will implicitly inherit from Object. Object’s parent is Kernel and Kernel’s parent is BasicObject so don’t be alarmed when you find Object, Kernel and BasicObject lurking in the ancestor hierarchy of most Ruby classes.

With the ancestor hierarchy in mind we can begin to dive into the include keyword. Include inserts the included module as a parent into a class or module. The included module’s methods are then accessible as instance methods. When inserted into a class this means that objects of that class can call the included module’s methods. The code below illustrates how this works:

module IncludedModule
  def was_included
    puts "Hello, I am from the IncludedModule"
  end
end

class MainClass
  include IncludedModule
end

MainClass.ancestors
# [MainClass, IncludedModule, Object, Kernel, BasicObject]

mc = MainClass.new
mc.was_included
# Hello, I am from the IncludedModule

We can see that the IncludedModule has been inserted as a parent to MainClass. IncludedModule’s methods are accessible to MainClass objects, meaning they are now instance methods of MainClass.

Note that as modules cannot be instantiated, including a module in another module does not have an obvious effect (besides altering the module’s ancestors). However, the included module’s methods are still added as instance methods. So when a class includes this module, it will allow objects of the class to access both the module’s methods and the methods of the module, the module included. If at this point you feel sick of the word “module”, let me apologise and lay it out visually:

Extend works like include but instead of adding included methods as instance methods, it adds them as class or module methods. This means that they can be accessed from the class or module but not from an instance:

module ExtendedModule
  def was_extended
    puts "Hello, I am from the ExtendedModule"
  end
end

class MainClass
  extend ExtendedModule
end

MainClass.ancestors
# [MainClass, Object, Kernel, BasicObject]

MainClass::was_extended
# Hello, I am from the ExtendedModule

mc = MainClass.new
mc.was_extended
# NoMethodError

Extend is unique in that it does not change the inheritance hierarchy

module MainModule
  extend ExtendedModule
end

MainModule::was_extended
# Hello, I am from the ExtendedModule

As a bonus it allows modules to share each other’s methods

Last but not least is prepend. Prepend works in a similar way to include but instead of the inserted module being added as a parent in the inheritance hierarchy, it is added as a child. This means that if there are overlapping methods between the included module and the main class/module the included methods override the others:

module PrependedModule
  def was_prepended
    puts "Hello, I am from the PrependedModule"
  end
end

class MainClass
  prepend PrependedModule

  def was_prepended
    puts "Hello, I am from the MainClass
  end
end

MainClass.ancestors
# [PrependedModule, MainClass, Object, Kernel, BasicObject]

mc = MainClass.new
mc.was_prepended
# Hello, I am from the Prepended Module

As the prepended module sits at the bottom of the hierarchy, its method gets called instead of the method defined in the class

Hopefully this has taught you something new about Ruby’s code insertion keywords. Moving code around programmatically is often overlooked, but knowing exactly the right keyword for your use-case could prevent a few headaches down the line. Stay tuned for another post next week, I’ve lined up something that will have you on the edge of your seat: logical operators.