Forem: Adrian Lee

Ruby: Call me (in which an old dog learns new tricks)

Adrian Lee — Mon, 03 Oct 2022 20:46:03 +0000

A few years ago I worked somewhere where the lead dev wanted us to adhere to SRP and expose the class and instance via a single interface named call e.g:

def Foo
  def self.call = new.call
  def call = "hello"
end

This actually ended up making a pretty clean codebase in certain respects (certainly helped ease the problem of naming things) although ignoring more obvious conventions such as to_h when returning a hash, to_s for strings etc eventually left me feeling it was too rigorously applied.

That aside, one of the missed opportunities was in generating a broader understanding of why a class/instance like this is useful and I recently had an opportunity to revisit the question.

In case you aren't aware, there are couple of ruby objects which already respond to call namely lambda and proc.

l = lambda { |x| x * x }
puts l.call(2) # 4

p = proc { |x| x + x }
puts p.call(3) # 6

You can also covert a method into a proc using method or (preferably) public_method:

def foo(x) = x - x
m = method(:foo)
puts m.call(10) # 0

With this in mind you can pass around a lambda, a proc, a method, a class, or an instance of a class, all executed with the same interface. This is very useful for callbacks and differed execution.

As for tricks ... there are several ways to actually call call. l.call(2) is obvious but you can also do l.(2).

For procs, lambdas, and methods, there is also l[2] and l.yield(2) (I didn't know this!) but in the case of a class or instance, you'll have to add support (e.g. alias_method :[], :call) which starts to make the class a little messy, so I tend to stick with .().

But there's more. if you're a fan of Elixirs pipes:

l = lambda { |x| x * x }
p = proc { |x| x + x }
output = proc { |x| puts "*** #{x} ***" }

(l >> p >> output).call(2) # *** 8 ***
(output << p << l).call(2) # *** 8 ***

I don't know that I'd approve code like this in a PR unless there was a really good reason but I had no idea this was possible. New tricks!

Ruby: When to use protected

Adrian Lee — Sun, 02 Oct 2022 12:12:12 +0000

One of my pet peeves (I have a few) is finding the protected keyword in the wild because 99% of the time (seriously) the developer does not understand its use.

The use case is simple. You want an instance of a class to be able to access what would normally be private within another instance of the same class. For example, you are trying to apply an operation (e.g. multiply) on some item of state within the two classes; it has to be possible for one of the classes to reach into the other class and get a value for the operation to be applied.

Using multiply as an example:

class A
  def initialize(value) = @value = value

  def *(other) = value * other.value

  protected

  attr_reader :value
end

a1 = A.new(3)
a2 = A.new(4)

puts a1 * a2

It should be no surprise that this prints 12 when run.

If the value has been private rather than protected the output would be:

protected.rb:5:in `*': private method `value' called for #<A:0x000000010520e1c0 @value=4> (NoMethodError)

  def *(other) = value * other.value
                              ^^^^^^
        from protected.rb:15:in `<main>'

So protected has nothing to do with inheritance (as many people seem to think), everything to do with constraining access to state only to instances of the same class.

I give the slightly more lengthy explanation there because the question does arise of why not to just use public? The answer, to quote myself, encapsulation is vital in complex software systems. Everything that is public increases the surface area of a class and hence the cognitive overhead when working with the code. A classes public surface area should be as small as possible and protected allows you to achieve this.

Ruby: Why to use private_constant (pt 1)

Adrian Lee — Sat, 01 Oct 2022 22:29:16 +0000

I don't want to muddy the waters by going over all the reasons to use private_constant (e.g. for inner classes, that's pt 2) since I want to focus on what we most commonly think of as constants in ruby i.e. FOO = 1.

I'm too used to seeing classes that define constants at the top of the class (great!) but then leave me wondering .. is that constant being used from outside the class? In a small code base that isn't a problem; in a large code base it's essential that a classes public interface is public for a reason, not by chance.

Sometimes people do consider this and we end up with:

class Foo
   def blahblah = FOO
...
  private
  FOO = 1
end
puts Foo:FOO

:shocked_pikachu_face: when people discover that the above quite happily prints 1

The proper way to declare a private constant is to use ... private_constant

class Foo
  FOO = 1
  private_constant :FOO

  def blahblah = FOO
end
puts Foo::FOO

Now we have a private constant:

ruby private_constants.rb
private_constants.rb:7:in `<main>': private constant Foo::FOO referenced (NameError)

puts Foo::FOO
        ^^^^^

Encapsulation is vital in complex software systems. Please watch your privates!

Ruby: Why to use private attr_reader

Adrian Lee — Sat, 01 Oct 2022 22:10:13 +0000

I was just reminded of why I use private att_reader in my code.

I know the advice is to always use an interface but a point of discussion between myself and a colleague has been why not to use an instance variable, with the argument that it is much more readable.

I have to agree with him in that with @foo it's obvious that it's an instance variable being referred to. I agree it's better than plain old foo in terms of readability.

That is about where the benefit ends however and there is a huge downside. Consider the following:

class Foo
  def initialize(some_variable) = @some_variable = some_variable
  def some_op = @some_varible
end

class BetterFoo
  def initialize(some_variable) = @some_variable = some_variable

  def some_op = some_varible

  private attr_reader :some_variable
end

puts "----"
puts Foo.new("BAR").some_op
puts "----"
puts BetterFoo.new("BAR").some_op
puts "----"

The typo in the above is probably glaringly obvious since it's a small piece of code ... did you spot it? If not compare the output:

ruby some_variable.rb
----

----
some_variable.rb:10:in `some_op': undefined local variable or method `some_varible' for #<BetterFoo:0x00007fdba9d26090 @some_variable="BAR"> (NameError)

  def some_op = some_varible
                ^^^^^^^^^^^^
Did you mean?  some_variable
               @some_variable
    from some_variable.rb:18:in `<main>'

Did you spot it now?

IMO the use of a private attr_reader so as to ensure the variable you are using has been initialised to a value other than nil overrides any readability argument; let's not mention that it more easily allows the interface to be changed internally in the future should the need arise. The fact that it's private makes it an implementation detail but an implementation detail that will save you a lot of time.