DEV Community: Mehdi FARSI

Evolution of String since Ruby 1.8

Mehdi FARSI — Tue, 10 Sep 2019 13:36:49 +0000

Scope Gates in Ruby: Part II

Mehdi FARSI — Thu, 05 Sep 2019 08:58:24 +0000

When we use the module keyword:

The value of self changes
The content of the module is embedded in an isolated scope
SEE MORE

The Inherited Hook Method in Ruby - and More Parenting Lessons

Mehdi FARSI — Tue, 03 Sep 2019 13:53:39 +0000

Hello children and parents, ahem Rubyists. In an earlier article, we dove into the ancestry chain. In today's post, we'll dive deeper into parenting and inheritance. We will explore the inherited hook method and look into preventing inheritance.

When Kids Inherit 101: The Inherited Hook Method

Let's start with a look at how parenthood is declared. Ruby provides a neat way of interacting with a class when it is declared as the parent of another class.

class Parent
  def self.inherited(subclass)
    puts "#{subclass} inherits from Parent"
  end
end

class Child < Parent
end

Running this code prints out "Child inherits from Parent", as the Parent.inherited method is called when the Child class inherits from Parent. Note that this method takes the subclass as parameter—Child, in our case. This mechanism allows you to interact with the Parent class to define a set of behaviors only if it is inherited. By behavior, in this context, we mean modifying, defining or deleting variables, methods and constants on the inheriting or the inherited class.

Now, let's define the parent_name method on-the-fly:

class Parent
  def self.inherited(subclass)
    subclass.define_method :parent_name do
      "Daddy"
    end
  end
end

class Child < Parent
end

Child.new.parent_name # => "Daddy"

Here, we define a method on the Child class when it inherits from the Parent class, but without adding that method directly to the Parent class. Instead, it's only defined when another class inherits from Parent.

Alright, we've covered the theory, now let’s take a look at a more realistic example in the life of a Rubyist.

Prevent Class Inheritance

In Ruby on Rails, database migrations are handled by the ActiveRecord::Migration class. Let’s try to directly inherit from this class.

class AddFirstnameToUsers < ActiveRecord::Migration
end

# => StandardError (Directly inheriting from ActiveRecord::Migration is not supported..)

This error is raised because Ruby on Rails provides a mechanism that prevents us from inheriting from this class. So why did Ruby on Rails implement this mechanism?

A migration is strongly coupled to a specific version of Ruby on Rails. Indeed, the API provided by this class can slightly change between 2 versions. So, to avoid breaking migrations when you upgrade Ruby on Rails, the framework forces you to choose a specific version of the ActiveRecord::Migration class. This ensures the smooth running of your migrations.

class AddFirstnameToUsers < ActiveRecord::Migration[4.2]
end

In the example above, our migration is coupled to the ActiveRecord::Migration API provided with version 4.2 of Ruby on Rails. So, even if we upgrade our application to version 5.0, our migrations will still run smoothly because they'll still run with version 4.2 of the ActiveRecord::Migration API.

How Preventing Inheritance Works

Now that we understand why inheritance is prevented here, let’s see how this ActiveRecord::Migration prevents inheritance. All the logic is defined in the ActiveRecord::Migration.inherited method.

class AddFirstnameToUsers < ActiveRecord::Migration[4.2]
end

When our AddFirstnameToUsers class inherits from ActiveRecord::Migration, the ActiveRecord::Migration.inherited hook method is called.

module ActiveRecord
  class Migration
    def self.inherited(subclass) #:nodoc:
      super
      if subclass.superclass == Migration
        raise StandardError, "Directly inheriting from ActiveRecord::Migration is not supported. " \
          "Please specify the Rails release the migration was written for:\n" \
          "\n" \
          "  class #{subclass} < ActiveRecord::Migration[4.2]"
      end
    end
  end
end

As we can see, this hook method checks if the subclass (AddFirstnameToUsers) directly inherits from ActiveRecord::Migration. If it does, an error is raised. This is the perfect entry point for controlling inheritance.

Conclusion

Today, we covered the basics of inheritance and preventing inheritance. We covered the inherited hook method and saw how it can be very handy when interacting with the inheriting/inherited class on-the-fly.

In a real-world setting, watch out when playing with inheritance. Be very cautious when you remove or override an existing method or class. This could result in some unwanted side effects. Children may stop calling you daddy.

Et Voilà, this concludes our post for today!

The guide to enjoy your first developer job

Mehdi FARSI — Tue, 03 Sep 2019 11:38:59 +0000

This guide will give you the tools to get the best of your future developer job.. SEE MORE

Magic comments in Ruby

Mehdi FARSI — Thu, 15 Aug 2019 08:29:43 +0000

In this article, we’re going to explore the following topics:

comments vs magic comments
specifications
existing magic comments
SEE MORE

Up the Ruby Ancestor Chain with method_missing

Mehdi FARSI — Wed, 08 May 2019 10:50:30 +0000

Clutch your carry-on luggage, because today we'll travel all the way up the ancestor chain. We'll follow a method call and see how it goes up the chain as well as find out what happens if the method is missing. And because we love to play with fire, we won't stop there but continue on to ~~playing with fire~~ overriding the BasicObject#method_missing. If you pay attention, we might also use it in a practical example. No guarantees though. Let's go!

The Ancestor Chain

Let's start with the fundamental rules of ancestor chains in Ruby:

Ruby only supports single inheritance
It also allows an object to include a set of modules

In Ruby, the ancestor chain is composed of the traversal of all the inherited classes and modules for a given class.

Let’s have a look at an example to show you how the ancestor chain is handled in Ruby.

module Auth end

module Session end

module Iterable end

class Collection
  prepend Iterable
end

class Users < Collection
  prepend Session
  include Auth
end

p Users.ancestors

produces:

[
  Session, Users, Auth,        # Users
  Iterable, Collection,        # Collection
  Object, Kernel, BasicObject  # Ruby Object Model
]

First, we call the ancestors class method to access the ancestor chain of a given class.

We can see that a call to Users.ancestors returns an array of classes and modules that contain, in order:

The prepended modules of Users
The Users class
The Users class’ included modules
The Collection class’ prepended modules — as the direct parent of Users
The Collection class
The Collection class’ included modules — none
The Object class — the default inheritance of any class
The Kernel module — included in Object and holding core methods
The BasicObject class — the root class in Ruby

So, the order of appearance for a given traversed class or module is always as follows:

The prepended modules
The class or module
Its included modules

The ancestor chain is mainly traversed by Ruby when a method is invoked on an object or a class.

The Method Lookup Path

When a message is sent, Ruby traverses the ancestor chain of the message receiver and checks if any of them responds to the given message.

If a given class or module of the ancestor chain responds to the message, then the method associated with this message is executed and the ancestor chain traversal is stopped.

class Collection < Array
end

Collection.ancestors # => [Collection, Array, Enumerable, Object, Kernel, BasicObject]

collection = Collection.new([:a, :b, :c])

collection.each_with_index # => :a

Here, the collection.each_with_index message is received by the Enumerable module. Then the Enumerable#each_with_index method is called for this message.

Here, when collection.each_with_index is called, Ruby checks if:

Collection responds to the each_with_index message => NO
Array responds to the each_with_index message => NO
Enumerable responds to the each_with_index message => YES

So, from here, Ruby stops the ancestor chain traversal and calls the method associated with this message. In our case, the Enumerable#each_with_index method.

In Ruby, this mechanism is called the Method Lookup Path.

Now, what happens if none of the classes and modules that compose a given receiver’s ancestor chain respond to the message?

`BasicObject#method_missing`

Enough with playing nice! Let's break things, developer style: by throwing exceptions. We'll implement a Collection class and call an unknown method on one of its instances.

class Collection
end

c = Collection.new
c.search('item1') # => NoMethodError: undefined method `search` for #<Collection:0x123456890>

Here, the Collection class doesn't implement a search method. So a NoMethodError is raised. But where does this error raising comes from?

The error is raised in the BasicObject#method_missing method. This method is called when the Method Lookup Path ends up not finding any method corresponding to a given message.

Okay... but this method only raises a NoMethodError. So it would be great to be able to override the method in the context of our Collection class.

Overriding the `BasicObject#method_missing` Method

Guess What? It’s totally fine to override method_missing as this method is also subject to the mechanism of Method Lookup Path. The only difference with a normal method is that we’re sure that this method will be found at least once by the Method Lookup Path.

Indeed, the BasicObject class — which is the root class of any class in Ruby — defines a minimal version of this method. Classic Ruby Magic, n'est pas?

So let’s override this method in our Collection class:

class Collection
  def initialize
    @collection = {}
  end

  def method_missing(method_id, *args)
    if method_id[-1] == '='
      key = method_id[0..-2]
      @collection[key.to_sym] = args.first
    else
      @collection[method_id]
    end
  end
end

collection = Collection.new
collection.obj1 = 'value1'
collection.obj2 = 'value2'

collection.obj1 # => 'value1'
collection.obj2 # => 'value2'

Here, the Collection#method_missing acts as a delegator to the @collection instance variable. Actually, this is the way Ruby roughly handles object delegation — c.f: the delegate library.

If the missing method is a setter method (collection.obj1 = 'value1'), then the method name (:obj1) is used as the key and the argument ('value1') as the value of the @collection hash entry (@collection[:obj1] = 'value1').

An HTML Tag Generator

Now that we know how the method_missing method works behind the scenes, let’s implement a reproducible use case.

Here, the goal is to define the following DSL:

HTML.p    'hello world'             # => <p>hello world</p>
HTML.div  'hello world'             # => <div>hello world</div>
HTML.h1   'hello world'             # => <h1>hello world</h1>
HTML.h2   'hello world'             # => <h2>hello world</h2>
HTML.span 'hello world'             # => <span>hello world</span>
HTML.p    "hello #{HTML.b 'world'}" # => <p>hello <b>world</b></p>

To do so, we’re going to implement the HTML.method_missing method in order to avoid defining a method for each HTML tag.

First, we define an HTML module. Then we define a method_missing class method in this module:

module HTML
  def HTML.method_missing(method_id, *args, &block)
    "<#{method_id}>#{args.first}</#{method_id}>"
  end
end

Our method will simply build an HTML tag using the missing method_id — :div for a call to HTML.div, for example.

Note that class methods are also subject to the Method Lookup Path.

We could enhance our HTML tag generator by:

using the block argument to handle nested tags
handling single tags — <br/> for example

But note that with a few lines of code, we are able to generate a huge amount of HTML tags.

So, to recap:

method_missing is a good entry point to create DSLs where most of the commands will share a set of identified patterns.

Conclusion

We went all the way up the ancestor chain in Ruby and dove into BasicObject#method_missing. BasicObject#method_missing is part of the Ruby Hook Methods. It is used to interact with objects at some precise moments in their lifecycle. Like any of the other Ruby Hook Methods, this hook method has to be used carefully. And by carefully, we mean that it should never modify the behaviors of the Ruby Object Model—except when you are playing around with it or writing a blog post on it ;-)

Voilà!

Guest author Mehdi Farsi is the founder of www.rubycademy.com which will offer cool courses to learn Ruby and Ruby on Rails when it launches soon.

Object Marshalling in Ruby

Mehdi FARSI — Fri, 29 Mar 2019 10:06:20 +0000

In this article, we’re going to dive into object marshalling. We'll explain what it is, look at the Marshall module, and then go through an example. We'll then go a step deeper and compare the _dump and self._load methods. Let's go!

What’s Object Marshalling?

When you are writing code, you might want to save an object and transmit it to another program or reuse it in your next program execution. Object marshalling is used in Sidekiq, for example; when a Sidekiq job is enqueued in a Ruby on Rails application, then a serialization of this job — which is nothing more than an object — is inserted in Redis. The Sidekiq process is then able to deserialize this JSON and reconstitute the original job from the JSON.

In computer programming, this process of serialization and deserialization of an object is what we commonly call object marshalling. Now, let’s look at what Ruby natively provides to handle Object Marshalling.

The Marshal Module

As Ruby is a fully object oriented programming language, it provides a way to serialize and store objects using the Marshall module in its standard library. It allows you to serialize an object to a byte stream that can be stored and deserialized in another Ruby process.

So, let’s serialize a string and take a closer look at the serialized object.

hello_world = 'hello world!'

serialized_string = Marshal.dump(hello_world) # => "\x04\bI\"\x11hello world!\x06:\x06ET"
serialized_string.class                       # => String

deserialized_hello_world = Marshal.load(serialized_string) # => "hello world!"

hello_world.object_id              # => 70204420126020
deserialized_hello_world.object_id # => 70204419825700

We then call the Marshal.dump module method to serialize our string. We store the return value—which contains our serialized string—in the serialized_string variable. This string can be stored in a file and the file can be reused to reconstitute the original object in another process. We then call the Marshal.load method to reconstitute the original object from the byte stream.

We can see that this freshly reconstituted string has a different object_id than the hello_world string, which means it's a different object, but it contains the same data.

Pretty cool! But how is the Marshal module able to reconstruct the string? And, what if I want to have control over which attributes to serialize and deserialize?

A Concrete Example of Object Marshalling

To answer these questions, let’s implement a marshalling strategy on a custom struct named User.

User = Struct.new(:fullname, :age, :roles)

user = User.new('Mehdi Farsi', 42, [:admin, :operator])

The User struct defines 3 attributes: fullname, age, and roles. For this example we have a business rule where we only serialize when it matches the following criteria:

The fullname contains less than 64 characters
The roles array does not contain the :admin role

To do so, we can define a User#marshal_dump method to implement our custom serialization strategy. This method will be called when we invoke the Marshal.dump method with an instance of User struct as parameter. Let’s define this method:

User = Struct.new(:age, :fullname, :roles) do
  def marshal_dump
    {}.tap do |result|
      result[:age]      = age
      result[:fullname] = fullname if fullname.size <= 64
      result[:roles]    = roles unless roles.include? :admin
    end
  end
end

user = User.new(42, 'Mehdi Farsi', [:admin, :operator])

user_dump = Marshal.dump(user) # 'in User#marshal_dump'
user_dump                      # => "\x04\bU:\tUser{\a:\bageI\"\x10Mehdi Farsi\x06:\x06ET:\rfullnamei/"

In the above example, we can see that our User#marshal_dump method is called when we invoke Marshal.dump(user). The user_dump variable contains the string which is the serialization of our User instance.

Now that we have our dump, let’s deserialize it to reconstitute our user. To do so, we define a User#marshal_load method which is in charge of implementing the deserialization strategy of a User dump.

So let’s define this method.

User = Struct.new(:age, :fullname, :roles) do
  def marshal_dump
    {}.tap do |result|
      result[:age]      = age
      result[:fullname] = fullname if fullname.size <= 64
      result[:roles]    = roles unless roles.include? :admin
    end
  end

  def marshal_load(serialized_user)
    self.age      = serialized_user[:age]
    self.fullname = serialized_user[:fullname]
    self.roles    = serialized_user[:roles] || []
  end
end

user = User.new(42, 'Mehdi Farsi', [:admin, :operator])

user_dump = Marshal.dump(user) # 'in User#marshal_dump'
user_dump                      # => "\x04\bU:\tUser{\a:\bagei/:\rfullnameI\"\x10Mehdi Farsi\x06:\x06ET"

original_user = Marshal.load(user_dump)  # 'in User#marshal_load'
original_user                            # => #<struct User age=42, fullname="Mehdi Farsi", roles=[]>

In the above example, we can see that our User#marshal_load method is called when we invoke Marshal.load(user_dump). The original_user variable contains a struct which is a reconstitution of our user instance.

Note that the original_user.roles is not similar to the user.roles array since during the serialization, user.roles included the :admin role. So the user.roles wasn’t serialized into the user_dump variable.

The _dump and self._load Methods

When Marshal.dump and Marshal.load are invoked, these methods call the marshal_dump and the marshal_load methods on the object passed as the parameter of these methods.

But, what if I tell you that the Marshal.dump and the Marshal.load methods try to call two other methods named _dump and self._load on the object passed as parameter?

The _dump Method

The differences between the marshal_dump and the _dump methods are:

you need to handle the serialization strategy at a lower level when using the _dump method — you need to return a string that represents the data to serialize
the marshal_dump method takes precedence over _dump if both are defined

Let’s have a look to the following example:

User = Struct.new(:age, :fullname, :roles) do
  def _dump level
    [age, fullname].join(':')
  end
end

user = User.new(42, 'Mehdi Farsi', [:admin, :operator])

Marshal.dump(user) # => "\x04\bIu:\tUser\x1342:Mehdi Farsi\x06:\x06EF"

In the User#_dump method, we have to instantiate and return the serialization object — the string that represents your serialization.

In the following example, we define User#marshal_dump and User#_dump methods and return a string to see which method is called

User = Struct.new(:age, :fullname, :roles) do
  def marshal_dump
    'in User#marshal_dump'
  end

  def _dump level
    'in User#_dump'
  end
end

user = User.new(42, 'Mehdi Farsi', [:admin, :operator])

user_dump = Marshal.dump(user) # "in User#marshal_dump"

We can see that only the User#marshal_dump is called even though they’re both defined.

The self._load Method

Now, let's look at the marshal_load and _load methods.

The differences between the marshal_load and the _load methods are:

You need to handle the deserialization strategy at a lower level when using the _load method — You are in charge of instantiating the original object.
The marshal_load method takes a deserialized object as an argument when the _self.load method takes the serialized string as an argument.
The marshal_load method is an instance method when the self._load is a class method.

Let’s take a look at the following example:

User = Struct.new(:age, :fullname, :roles) do
  def _dump level
    [age, fullname].join(':')
  end

  def self._load serialized_user
    user_info = serialized_user.split(':')
    new(*user_info, Array.new)
  end
end

user = User.new(42, 'Mehdi Farsi', [:admin, :operator])

user_dump = Marshal.dump(user)
user_dump # => "\x04\bIu:\tUser\x1342:Mehdi Farsi\x06:\x06EF"

original_user = Marshal.load(user_dump)
original_user # => #<struct User age="Mehdi Farsi", fullname=42, roles=[]>

In the User._load method:

we deserialize the string returned by the User#_dump method
we instantiate a new User by passing the deserialized information

We can see that we are in charge of allocating and instantiating the object used to reconstitute our original user.

So the Marshal.load coupled to marshal_load takes care of instantiating the reconstituted original object. Then it calls the marshal_load method with the serialized object passed as argument on the freshly instantiated object.

On the contrary, a call to Marshal.load coupled to _load lets the self._load class method be in charge of:

deserializing the data returned by the _dump method
instantiating the reconstituted original object

Conclusion

Depending on your needs, you can decide to implement a higher or lower serialization/deserialization strategy. To do so, you can use the Marshal module coupled to the appropriate Marshal hook methods.

Voilà!

Guest author Mehdi Farsi is the founder of www.rubycademy.com which will offer cool courses to learn Ruby and Ruby on Rails when it launches soon.

DEV Community: Mehdi FARSI

Evolution of String since Ruby 1.8

Scope Gates in Ruby: Part II

The Inherited Hook Method in Ruby - and More Parenting Lessons

When Kids Inherit 101: The Inherited Hook Method

Prevent Class Inheritance

How Preventing Inheritance Works

Conclusion

The guide to enjoy your first developer job

Magic comments in Ruby

Up the Ruby Ancestor Chain with method_missing

The Ancestor Chain

The Method Lookup Path

BasicObject#method_missing

Overriding the BasicObject#method_missing Method

An HTML Tag Generator

Conclusion

Object Marshalling in Ruby

What’s Object Marshalling?

The Marshal Module

A Concrete Example of Object Marshalling

The _dump and self._load Methods

The _dump Method

The self._load Method

Conclusion

`BasicObject#method_missing`

Overriding the `BasicObject#method_missing` Method