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, ...
For further actions, you may consider blocking this person and/or reporting abuse
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:
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 :) gitlab.com/snippets/1791110
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"
when2
will do.Nice article, thank you for this. Definatly something I can use in the future while I learn Ruby more.