Truth tables as Ruby Hashes

Fred Heath on December 17, 2018

Truth tables are a common way of defining and testing code behaviour. A truth table treats a component or function of our system as a black box, ... [Read Full]
markdown guide

While this is clever, be careful when doing this in production code. That temporary object is used once and thrown away, only to be generated again on the next instantiation. This creates a lot of “garbage” that needs to be cleaned up.

In situations like this you really want a constant, you can use that over and over to get a lot of mileage out of it. Since February is really the only “special” month you can have a look-up table with a tiny bit of logic built in, like in a lambda, which accounts for the leap year.

A Hash with a dynamic generator could also work, as it could fill in years as they’re referenced based on leap/non-leap and use just two look-up hashes internally.

Consider what you can do with:

CALENDAR = do |h,y|
  h[y] = ((y % 4 == 0) && ((y % 100 != 0) || (y % 400 == 0))) ? LEAP : NON_LEAP

Where this does the leap calculation at most once per year and links to the same hashes repeatedly.


That's a nice way of doing it Scott, it's cool to get different perspectives. You make a good point about re-generating objects too and this is certainly true in my example above. But, as I mention in the post, memoizing the Hash mitigates this problem :)


While that's better it still creates clutter in your object. A default inspect will show @h = ... even though that's not really relevant to that object. There's no reason to create this per-object, either, it doesn't change. That's why I recommend as a constant, out of the way and implicitly shared.

Also remember that months have commonly recognized numerical identifiers, there's no need to say "feb" when 2 will do.


Nice article, thank you for this. Definatly something I can use in the future while I learn Ruby more.

code of conduct - report abuse