Added TTL cache capability

[benasher44]

In #32, I wanted to add what basically amounts to the ability to make the caches behave like a TTL cache. I've done this with tests, which I think clearly illustrate the behavior I was going for here. I'm pretty open to discussion on this, and I've made sure that this is opt-in, so existing behavior of the caches should be unaffected.

[garrettmoon]

Neat! I'll try and look at this soon (next week by the latest). My greatest concern about this is making sure there are no performance impacts if this new feature is disable.

[benasher44]

@garrettmoon cool thanks! I think it should be alright performance-wise. In all cases, I check !self->_ttlCache before starting the TTL cache behavior, so performance impact should be minimal

[garrettmoon]

Can you make this nonatomic and also create a getter which grabs the ivar in self.lock?

[garrettmoon]

I think we need setTTLCache too? Otherwise they'll be set outside of the lock.

[benasher44]

It definitely does. I'm not sure why I missed that.

[garrettmoon]

Should ttl cache be exposed on PINCache too? Or only PINMemoryCache and PINDiskCache?

[benasher44]

I can't think of why you would want to use this feature on either only PINMemoryCache or PINDiskCache, but I'd say the same thing about ageLimit (also not exposed in PINCache.h), which ttlCache depends on (ttlCache = YES doesn't mean anything if ageLimit is 0). There's also some added complexity if you go that route. Let's say you do the following:

cache.ttlCache = YES;
cache.diskCache.ttlCache = NO;
NSLog(@"%@", cache.ttlCache ? @"YES" : @"NO");

What would you expect cache.ttlCache to print in this scenario? I think you avoid running into any bugs related to this situation, if you require clients to access ttlCache via either of the sub-caches.

[garrettmoon]

@benasher44 you've convinced me :)