ScalaCache API Updates Proposal

[lewisjkl]

There are a few issues where various API updates have been mentioned. This issue is to consolidate discussion about them and track their progress in one spot. All of these API updates should happen prior to version 1.0.0-RC1.

1. Support for polymorphic keys. Here we will use a KeyEncoder type class rather than the vararg key parts of type Any. This will allow us to use a generic type K to represent the key, and will give users full flexibility to use whatever key they want. See Support polymorphic keys #355 for more inforamation.
2. Cache-specific functionality. Here I think it makes the most sense to keep cache-specific functionality isolated to the cache implementation it is specific to. There is potential for abstraction in the future, but I don't think trying to create that now would be very effective without having more concrete use cases. See Cache-specific functionality #349 for more info.
3. Multi-level caching. This one I think can wait until after 1.0.0-RC1 to be implemented as it shouldn't require any changes to AbstractCache directly. That being said, it will be difficult to decide how to handle things such as differing caches requiring differing KeyEncoder instances. I am going to leave this for future discussion as I don't have a great answer at the moment. See Implement multi level cache #459 for more info.
4. Replace CacheAlg#close with resource-based API. I am thinking this will just mean getting rid of the close method and returning a Resource[F, MyCache] from the cache builder apply methods.
5. Logging abstraction. Assuming cats effect does not introduce its own logging abstraction (Davenverse components into std typelevel/cats-effect#1479), then I think it makes the most sense to create our own logging algebra and provide some interop modules for the most popular logging libraries.

In short, the changes we will make prior to ScalaCache 1.0.0-RC1 are:

• Introduce KeyEncoder type class
• Replace CacheAlg#close with a resource-based API
• Introduce a logging abstraction.

Questions/comments/suggestions are all very welcome here.

[tnielens]

Certain cache implementations provide atomicity on certain operations which are useful to prevent concurrency issues. See #159 and related blogpost https://softwaremill.com/race-condition-cache-guava-caffeine/

Would it make sense to add certain operations to the core algebra to leverage these guarantees in underlying implementations when available?
These two would be quite useful:

def getF(key: String, ifAbsent: F[V])
def putF(key: String, v: F[V])

That would guarantee that the value computations can't interleave with a cache invalidation operation for example like described in the linked blogpost. Due to the current scalacache algebra, these features aren't available to users.

You can ignore this, I hadn't found the caching and cachingF operations.