DEV Community


Discussion on: Truth tables as Ruby Hashes

tadman profile image
Scott Tadman • Edited

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.

redfred7 profile image
Fred Heath Author • Edited

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 :)

tadman profile image
Scott Tadman

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.