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 = Hash.new 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 :) 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.
@h = ...
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.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.