When calling an undefined ivar, it returns nil by default, however it does not create the ivar, thus there shouldn't be a performance penalty by this change, however it does improve readability imo.
if defined?(@expires_in) && defined?(@created_at) && @expires_in && @created_at
if @expires_in && @created_at`
What do you think?
Undefined ivars return nil by default
When called and undefined ivar, it does not create the ivar and
set it to nil, so there should not be a performance penalty
We need the defined checks otherwise we get Ruby warnings.
Although the proper solution here would be to initialize those variables in the initialize method, instead of having defined? checks creeping all over the source code.
I think these checks were needed because new instance variables have been added and there still exist cached instances of that class, which will not have these variables.
I guess initializing these variables in initialize will not work, since Marshal.load does not call initialize (it calls marshal_load, it that helps). I'm not actually sure whether or not marshalling is used as serialization mechanism.
The purpose is not to create uneeded ivars, because ivars take space in the serialized string and we want this to be extra efficient at the cost of some little unusual code, in order to tax the least small values like counters or flags.
I believe this one can be closed, we do not want warnings, and we want to create strictly the ivars we need for space efficiency (see discussion in -core). If this rationale is not clear enough in source code comments a patch to the comments could be discussed.
@fxn Not causing warnings is definitely a valid reason to not pull this in, I wasn't aware of this causing any warnings though. I didn't run Ruby in verbose mode when I was creating this commit. However after reading http://mislav.uniqpath.com/2011/06/ruby-verbose-mode/ it made more sense, perhaps we should mention the article in the contributing guides. Others might find this useful as well.
@ayrton yeah, no worries I am sure you didn't propose a patch that issued warnings knowing that it did.
On the other hand, test suites run with warnings enabled, and one would see in this case
.../cache.rb:647: warning: instance variable @expires_in not initialized
Warnings are already covered in the contributing guide, and one is assumed to run the suite before submitting a pull request, I believe that is enough.