DEV Community: Dino

Metaprogramming, ancestors chain and super.

Dino — Mon, 13 Mar 2023 08:07:09 +0000

Let's imagine we are building DSL similar to ActiveRecord associations.

class Person
  associated_with :account
end

Person.new.account # => "Account associated with a Person"

In order to build this feature, we will create a new module that dynamically defines association methods.

module Associations
  def associated_with(name)
    define_method(name) do
      puts "associated #{name}"
    end
  end
end

class Person
  extend Associations

  associated_with :account
end

Person.new.account #=> "associated account"

define_method creates an instance method on a receiver, which is exactly what we need.

define_method basically has done this;

class Person
  ...

  def account
    "associated account"
  end
end

We can easily validate this theory by inspecting the ancestors chain and instance methods:

Person.ancestors # => Person,Object,Kernel,BasicObject
Person.instance_methods(false) # => [account]

Overwriting dynamically defined method

If we wish to overwrite a dynamically defined method we can do it without any problems since this is just a "regular" instance method (albeit defined with some metaprogramming)

class Person
  extend Associations

  associated_with :account

  def account
    "overridden"
  end
end

Person.new.account #=> "overridden"

But, calling a super when overriding will fail

def account
  super
  "overridden"
end

Person.new.account # => `account': super: no superclass method `account' for ...

This makes sense since we are calling super on the method we've completely overwritten.

In order for super to work the method need to be defined in Persons ancestors chain.

We can do this by generating a new module on the fly, including that module in the class and define dynamic methods on that module instead of the class itself.

module Associations
  # Create new module on the fly.
  # Include that module in the ancestor chain
  def generated_association_methods
    @generated_association_methods ||= begin
                                         mod = const_set(:GeneratedAssociationMethods, Module.new)
                                         include mod
                                         mod
                                       end
  end

  def associated_with(name)
    mixin = generated_association_methods

    # define methods on the newly created module
    mixin.define_method(name) do
      puts "associated #{name}"
    end
  end
end

class Person
  extend Associations

  associated_with :account
end

Now dynamically defined methods live inside the Person::GeneratedAssociationMethods, which is part of ancestors chain.

Person.ancestors # => Person,**Person::GeneratedAssociationMethods**, Object,Kernel,BasicObject
Person.instance_methods(false) # => []

So calling super will work fine:

def account
  super
  "overridden"
end

Person.new.account
  #=> "associated_account"
  #=> "overridden"

I've seen this pattern used in Rails codebase in multiple places where this kind of behaviour is needed.

✌️

ActiveRecord associations, scoped

Dino — Fri, 17 Feb 2023 05:39:19 +0000

ActiveRecord as a neat trick/ability which a lot of folks are not aware of.

You can pass a block to association, for example:

class Account < ApplicationRecord
 has_many :users, -> { where(admin: true) }
end

class User < ApplicationRecord
 belongs_to :account
end

What makes this even more interesting is that you can have multiple associations to the same model with different name and conditions.

class Account < ApplicationRecord
 has_many :users
 has_many :admin_users, -> { where(admin: true) }, class_name: "User"
end

Calling @account.users will return collection of all users, but calling @account.admin_users will return collection of only admin users.

To make things even more interesting, when creating a new record through the association will comply with the association condition.

@account.admin_users.create(name: "Admin User")

creates a new user with admin set to true.

Since, condition executes in the context of the association object, you can also use scopes.

class Account < ApplicationRecord
  has_many :users
  has_many :admin_users, -> { admins }, class_name: "User"
end

class User < ApplicationRecord
 belongs_to :account

 scope :admins, -> { where(admin: true) }
end

@account.admin_users # Works the same as examples above

This associations will also work for eager loading also, calling
Account.includes(:admin_users) will eager load admin users.

ActiveRecord can accomplish this because associations are built from Relation objects, and you can use Relation syntax to customize them.

Isn't this neat!

Meza: From PostgreSQL table to a JSON file

Dino — Sun, 17 Nov 2019 10:21:01 +0000

Ever wanted to export data from the PostgreSQL table into a JSON file?

👇

pg_cmd="\\copy (select row_to_json(r) from (select * FROM table_name) r ) to
table.json"
psql -w -h host -U username -d database_name -c $pg_cmd
sed -i -e 's/\\\\/\\/g' table.json # clean up extra '\' characters

After executing these commands you will have two JSON files

table.json - initial JSON exported data file
table.json-e - file which contains cleaned up JSON, without extra \ characters

✌️

Introduction to Ruby blocks

Dino — Tue, 12 Nov 2019 13:09:42 +0000

Blocks are ubiquitous in Ruby. They are one of the defining and most powerful characteristics of the Ruby language. It is almost impossible to write any meaningful Ruby code without the blocks. They appear everywhere from ruby core library methods such as enumerations to Rails to Rake to almost every gem out there.

# Core lib
10.times { puts "Ruby" }

# Rails
Rails.application.routes.draw do
  resources :people
end

# Rake
task :test do
  ruby "test/unittest.rb"
end

# Bundler
group :development do
  gem 'pry-byebug'
end

Blocks, all over the place 😰😱

Yet, they can be so hard to understand for beginners and even experienced programmers that are just starting with Ruby.

In this post, we will look at what are the closures, blocks and basic usage patterns.

Let's begin!

Scopes

Lexical scope

Lexical scope serves to answer one important question: What is the value of this variable at this line?

def speak
  message = "in the bottle"
  message
end

speak
# => "in the bottle"

In this example, we created a local variable inside the method, the variable is in the scope of the method, it is created there.

message = "in the bottle"

def speak
  message
end

speak
# => NameError (undefined local variable or method `message' for main:Object)

In this example, we created the variable outside the method scope. When we call the variable inside the method we get an error: Variable is out of the scope.

Local variables are tightly scoped, we can't access a variable outside itself unless it's passed as an argument, or we define an instance variable but that is a story for another day.

Inherited scopes

Yeah, yeah...we got it scoping rules explained above are nothing new and they are easy to grasp. But, wait how does this work then:

message = "in the bottle"

2.times do
  puts message
end

# => in the bottle
# => in the bottle

Blocks, Procs, Lambdas are different. Blocks create scope between do..end(same as method), but they inherit references to the local variables in the context where they are created.

In our example we have 2 scopes

Outer/parent - where variable message is defined
Inner/child - scope inside the block

Our block is created in the context of parent scope and he will carry a reference to the local variable defined in that scope, thus making message variable accessible from within the inner scope.

When block calls variable from the outer/parent scope, that variable is called a free variable.

Turns out, when function whose body(lexical scope) references a variable(free variable) that is declared in the parent scope we got a CLOSURE.

Blocks

Blocks are effectively a type of closure. Blocks capture pieces of code that can be passed into methods to be executed later, they act like anonymous functions.

The ability to encapsulate behavior into blocks and pass it to the methods is an extremely useful technique. This lets you separate general and specific pieces of your code.

Let us imagine we are developers for the NBA. We are building a register of the most popular players:

class Player
  attr_reader :name, :team, :salary, :age

  def initialize(name, team, salary, age)
    @name   = name
    @team   = team
    @salary = salary
    @age    = age
  end
end

players = []
palyers << Player.new("Lebron James", "Lakers", salary: 5000, age: 34)
palyers << Player.new("Kevin Durant", "Nets", salary: 4000, age: 31)
palyers << Player.new("James Harden", "Rockets", salary: 6000, age: 30)

We have a requirement to display players sorted by age or salary or name.

Instead of tying our class with specific sorting implementation we can leverage the power of blocks and separating general from specific like this:

players.sort_by { |player| player.age }
players.sort_by { |player| player.salary }
players.sort_by { |player| player.name }

Executing blocks

Whenever you see yield keyword that means execute the block, for example

def speak
  yield
end

speak method will execute any block we give it

speak { puts "Y" }
#=> Y

If we don't pass the block to the method, ruby will raise an exception.

speak 
# => LocalJumpError (no block given (yield))

Luckily ruby gives as a nice way to check whether the block was passed with block_given?

def speak
  if block_given?
    yield
  else
    "No block is given"
  end
end

speak { puts "Y" }
#=> Y 

speak
#=> No block is given

We can also pass arguments to the block to get similar behavior to this

speak("ruby") { |message| puts "Hello #{message}" }

def speak(message)
  yield(message)
end

Those with a sharp eye will notice that message variable is a free variable here.

That is all for now, in the next posts I will talk more about procs, lambdas, and interesting patterns that we can leverage procs, lambdas, and blocks for.

✌️