Boolean Externalities
Tags: ruby, boolean, externalities
Published: 2022-09-08 10:27:18

---
title: Boolean Externalities
published: true
date: 2014-09-18 23:53:00 UTC
tags: ruby,boolean,externalities
canonical_url: https://blog.narnach.com/blog/2014/boolean-externalities/
---

This is motivated/inspired by Avdi Grimm’s post on Boolean Externalties

[http://devblog.avdi.org/2014/09/17/boolean-externalities/](http://devblog.avdi.org/2014/09/17/boolean-externalities/)

In his post he asks the question: if a predicate returns false, why does it do so? If you chain a lot of predicates, it’s hard to figure out why you get the answer you get.

Consider this example. It implements simple chained predicate logic to determine if the object is scary.

```ruby
class SimpleBoo
  def scary?
    ghost? || zombie?
  end

  def ghost?
    !alive? && regrets?
  end

  def zombie?
    !alive? && hungry_for_brains?
  end

  def alive?
    false
  end

  def regrets?
    false
  end

  def hungry_for_brains?
    false
  end
end

```

Following the chain of logic, something is scary if it’s either a ghost or a zombie. They are both not alive, but a ghost has regrets and a zombie is hungry for brains. This is the code as I would probably write it for a production app. It’s simple and very easy to read.

The downside is that if you want to know _why_ something is scary, you have to go and read the code. You can not ask the object _why_ it arrived at its conclusion.

## Why

The following is a logical next step in the evolution of the code: I have modified the code so it can explain _why_ a predicate returns true or false, though there is a tremendous “cost” in length and legibility.


```ruby
class WhyNotBoo
  # The object is scary if there is a reason for it to be scary.
  def scary?
    why_scary.any?
  end

  # Why is this object scary?
  def why_scary
    reasons = []

    # Early termination if this object is *not* scary.
    return reasons unless ghost? || zombie?

    # Recursively determine why this object is scary.
    reasons.concat([:ghost => why_ghost]) if ghost?
    reasons.concat([:zombie => why_zombie]) if zombie?
    reasons
  end

  # For the "why not" question we re-implement the "why" logic in reverse.
  def why_not_scary
    reasons = []
    return reasons if ghost? || zombie?
    reasons.concat([:not_ghost => why_not_ghost]) unless ghost?
    reasons.concat([:not_zombie => why_not_zombie]) unless zombie?
    reasons
  end

  def ghost?
    why_ghost.any?
  end

  def why_ghost
    return [] unless !alive? && regrets?

    [:not_alive, :regrets]
  end

  def why_not_ghost
    reasons = []
    return reasons if ghost?

    reasons << :alive if alive?
    reasons << :no_regrets unless regrets?
    reasons
  end

  def zombie?
    why_zombie.any?
  end

  def why_zombie
    return [] unless !alive? && hungry_for_brains?

    [:not_alive, :hungry_for_brains]
  end

  def why_not_zombie
    reasons = []
    return reasons if zombie?

    reasons << :alive if alive?
    reasons << :not_hungry_for_brains unless hungry_for_brains?
    reasons
  end

  def alive?
    true
  end

  def regrets?
    false
  end

  def hungry_for_brains?
    false
  end
end

```

Yes, that’s a _lot_ more code. All composite predicates have a “why\_[predicate]” and a “why\_not\_[predicate]” version. Now you can ask if something is scary and why (or why not).

There are a few problems with this approach:

1. The logic is not in `scary?`, where you would expect it.
2. The logic is duplicated between `why_scary` and `why_not_scary`. Don’t Repeat Yourself, or you will get logic bugs.
3. There is a lot more code. A lot of boilerplate code, but also multiple concerns in the same method: bookkeeping and actual logic.

## Cleaner code

Let’s see if we can make the code legible again, while preserving the functionality of “why” and “why not”.


```ruby
class ReasonBoo < EitherAll
  def scary?
    either :ghost, :zombie
  end

  def ghost?
    all :not_alive, :regrets
  end

  def zombie?
    all :not_alive, :hungry_for_brains
  end

  def alive?
    false
  end

  def regrets?
    false
  end

  def hungry_for_brains?
    false
  end
end

```

So far, so good. The code is _very_ legibile, but there is a mysterious superclass `EitherAnd`. Before we look at _how_ it works, let’s look at _what_ it allows us to do:


```ruby
boo = ReasonBoo.new
boo.scary? # => false
boo.why_scary # => []
boo.why_not_scary # => [{:not_ghost=>[:not_regrets]}, {:not_zombie=>[:not_hungry_for_brains]}]

boo.ghost? # => false
boo.why_ghost # => []
boo.why_not_ghost # => [:not_regrets]

boo.zombie? # => false
boo.why_zombie # => []
boo.why_not_zombie # => [:not_hungry_for_brains]

```

For each predicate that uses `either` or `all` we can ask why or why not it’s true and the response is a chain of predicate checks.

## How we get cleaner code

If you want to make your code legible, there usually has to be some dirty plumbing code. In this example we have hidden this in a superclass, but it could have been a module as well without too much effort.

In order to keep the code easier to read, I have chosen to not extract duplicate logic into helper methods.

This class implements two methods: `either` and `all`.

Both methods have the same structure:

1. Setup the why\_[predicate] and why\_not\_[predicate] methods.
2. Evaluate each predicate until we reach a termination condition.
3. Track which predicates were true/false to explain _why_ we got the result we did.


```ruby
class EitherAll
  # This method mimics the behavior of "||". These two lines are functionally equivalent:
  #
  # ghost? || zombie? # => false
  # either :ghost, :zombie # => false
  #
  # The bonus of `either` is that afterwards you can ask why or why not:
  #
  # why_not_scary # => [{:not_ghost=>[:not_regrets]}, {:not_zombie=>[:not_hungry_for_brains]}]
  def either(*predicate_names)
    #
    # 1. Setup up the why_ and why_not_ methods
    #

    # Two arrays to track the why and why not reasons.
    why_reasons = []
    why_not_reasons = []

    # This is a ruby 2.0 feature that replaces having to regexp parse the `caller` array.
    # Our goal here is to determine the name of the method that called us.
    # In this example it is likely to be the `scary?` method.
    context_method_name = caller_locations(1, 1)[0].label

    # Strip the trailing question mark
    context = context_method_name.sub(/\?$/, '').to_sym

    # Set instance variables for why and why not for the current context (calling method name).
    # In our example, this is going to be @why_scary and @why_not_scary.
    instance_variable_set("@why_#{context}", why_reasons)
    instance_variable_set("@why_not_#{context}", why_not_reasons)

    # Create reader methods for `why_scary` and `why_not_scary`.
    self.class.class_eval do
      attr_reader :"why_#{context}", :"why_not_#{context}"
    end

    #
    # 2. Evaluate each predicate until one returns true
    #

    predicate_names.each do |predicate_name|
      # Transform the given predicate name into a predicate method name.
      # We check if the predicate needs to be negated, to support not_<predicate>.
      predicate_name_string = predicate_name.to_s
      if predicate_name_string.start_with?('not_')
        negate = true
        predicate_method_name = "#{predicate_name_string.sub(/^not_/, '')}?"
      else
        negate = false
        predicate_method_name = "#{predicate_name_string}?"
      end

      # Evaluate the predicate
      if negate
        # Negate the return value of a negated predicate.
        # This simplifies the logic for our success case.
        # `value` is always true if it is what we ask for.
        value = !public_send(predicate_method_name)
      else
        value = public_send(predicate_method_name)
      end

      #
      # 3. Track which predicates were true/false to explain *why* we got the answer we did.
      #

      if value
        # We have a true value, so we found what we are looking for.

        # If possible, follow the chain of reasoning by asking why the predicate is true.
        if respond_to?("why_#{predicate_name}")
          why_reasons << { predicate_name => public_send("why_#{predicate_name}") }
        else
          why_reasons << predicate_name
        end

        # Because value is true, clear the reasons why we would not be.
        # They don't matter anymore.
        why_not_reasons.clear

        # To ensure lazy evaluation, we stop here.
        return true
      else
        # We have a false value, so we continue looking for a true predicate
        if negate
          # Our predicate negated, so we want to use the non-negated version.
          # In our example, if `alive?` were true, we are not a zombie because we are not "not alive".
          # Our check is for :not_alive, so the "why not" reason is :alive.
          negative_predicate_name = predicate_name_string.sub(/^not_/, '').to_sym
        else
          # Our predicate is not negated, so we need to use the negated predicate.
          # In our example, we are not scary because we are not a ghost (or a zombie).
          # Our check is for :scary, so the "why not" reason is :not_ghost.
          negative_predicate_name = "not_#{predicate_name_string}".to_sym
        end

        # If possible, follow the chain of reasoning by asking why the predicate is false.
        if respond_to?("why_#{negative_predicate_name}")
          why_not_reasons << { negative_predicate_name => public_send("why_#{negative_predicate_name}") }
        else
          why_not_reasons << negative_predicate_name
        end
      end
    end
    # We failed because we did not get a true value at all (which would have caused early termination).
    # Clear all positive reasons.
    why_reasons.clear

    # Explicitly return false to match style with the `return true` a few lines earlier.
    return false
  end

  # This method works very similar to `either`, which is defined above.
  # I'm only commenting on the differences here.
  #
  # This method mimics the behavior of "&&". These two lines are functionally equivalent:
  #
  # !alive? && hungry_for_brains?
  # all :not_alive, :hungry_for_brains
  def all(*predicate_names)
    context_method_name = caller_locations(1, 1)[0].label
    context = context_method_name.sub(/\?$/, '').to_sym
    why_reasons = []
    why_not_reasons = []
    instance_variable_set("@why_#{context}", why_reasons)
    instance_variable_set("@why_not_#{context}", why_not_reasons)
    self.class.class_eval do
      attr_reader :"why_#{context}", :"why_not_#{context}"
    end

    predicate_names.each do |predicate_name|
      predicate_name_string = predicate_name.to_s
      if predicate_name_string.start_with?('not_')
        negate = true
        predicate_method_name = "#{predicate_name_string.sub(/^not_/, '')}?"
      else
        negate = false
        predicate_method_name = "#{predicate_name_string}?"
      end

      if negate
        value = !public_send(predicate_method_name)
      else
        value = public_send(predicate_method_name)
      end

      # The logic is the same as `either` until here. The difference is:
      #
      # * Either looks for the first true to declare success
      # * And looks for the first false to declare failure
      #
      # This means we have to reverse our logic.
      if value
        if respond_to?("why_#{predicate_name}")
          why_reasons << { predicate_name => public_send("why_#{predicate_name}") }
        else
          why_reasons << predicate_name
        end
      else
        if negate
          negative_predicate_name = predicate_name_string.sub(/^not_/, '').to_sym
        else
          negative_predicate_name = "not_#{predicate_name_string}".to_sym
        end

        if respond_to?("why_#{negative_predicate_name}")
          why_not_reasons << { negative_predicate_name => public_send("why_#{negative_predicate_name}") }
        else
          why_not_reasons << negative_predicate_name
        end

        why_reasons.clear
        return false
      end
    end

    why_not_reasons.clear
    return true
  end
end

```

## Conclusion

It is possible to provide traceability for _why_ a boolean returns its value with less than 200 lines of Ruby code and minor changes to your own code.

Despite the obvious edge cases and limitations, it’s nice to know there is a potential solution to the problem of not knowing _why_ a method returns `true` or `false`.