extract Cache::AbstractStore into its own file

[ghost]

This is a subtle style change, but IMO having parent classes like this in separate files is a cleaner approach, especially if they are designed to be inherited from.

[paul]

I agree, and was planning on doing that once I added a second cache store implementation. But actually, I had no idea anyone else was even using this, so thats awesome.

On Saturday, April 13, 2013 at 2:25 AM, Byron Bowerman wrote:

This is a subtle style change, but IMO having parent classes like this in separate files is a cleaner approach, especially if they are designed to be inherited from.
You can merge this Pull Request by running
git pull https://github.com/BM5k/faraday-cache refactor/abstract-store
Or view, comment on, or merge it at:
#1
Commit Summary
extract Cache::AbstractStore into its own file

File Changes
M lib/faraday/cache.rb (https://github.com/paul/faraday-cache/pull/1/files#diff-0) (1)
A lib/faraday/cache/abstract_store.rb (https://github.com/paul/faraday-cache/pull/1/files#diff-1) (10)
M lib/faraday/cache/memory_store.rb (https://github.com/paul/faraday-cache/pull/1/files#diff-2) (6)

Patch Links:
https://github.com/paul/faraday-cache/pull/1.patch
https://github.com/paul/faraday-cache/pull/1.diff

[ghost]

I got here from octokit/octokit.rb#142. I would like to implement caching for octokit in BM5k/ghsb. However, since I am hosting that on heroku, I would prefer a non-memory backend.

I am currently experimenting with adding a redis backend.