cb372/gitter.md

## gitter.md

      
    Raw
  

              gitter.md
            
          
    First of all, sorry for the radio silence. I forgot this channel existed, and Gitter
notifications have always been flaky for me.
Second, it sounds like the reasons behind adding a type parameter to Cache are
not very clear, so I'll explain below. Maybe I should add some kind of
design/architecture page to the microsite?
Third, thank you for all your work on the PR. Sorry again for not being
available to give feedback earlier.
About Cache vs Cache[V]

The thinking behind turning it into Cache[V] was mostly about improving type safety.
In the old API, because a Cache would accept all types, it was all too easy to
write a Foo and then read it back as a Bar, resulting in runtime exceptions.
In the new API, you can think of Cache[V] as a type class meaning "it is
possible to cache a value of type V. If you can find an instance of the
Cache[V] type class, you can cache your value of type V. If not, you are
trying to cache something that has the wrong type.
This works really well for the common case where you are only trying to cache
things of one type, e.g. User.
It also works well for the case where you maintain caches for a few different
types, say User and Product. In that case, you could still make the mistake
of writing a value as a User and then trying to read it back as a Product,
but you are protected from the class of errors that involves any other arbitrary
types, e.g. writing a String and then trying to read it as a Product.
In the case where you don't know the types beforehand, or rather you want your
cache to be able to store any arbitrary types, it's still possible to "opt out"
of this type safety, by having a Cache[Any]. It's just that you need to do the
nasty unsafe casting in userland instead of having it hidden away inside the
library like it used to be.
You could also write it like this, although it still involves casting. There's
no getting around that.
scala> import com.github.benmanes.caffeine.cache._
import com.github.benmanes.caffeine.cache._

scala> import scalacache._
import scalacache._

scala> import scalacache.caffeine._
import scalacache.caffeine._

scala> val underlying = Caffeine.newBuilder().build[String, Entry[Any]]()
underlying: com.github.benmanes.caffeine.cache.Cache[String,scalacache.Entry[Any]] = com.github.benmanes.caffeine.cache.UnboundedLocalCache$UnboundedLocalManualCache@672debf8

scala> implicit def caffeineCache[V](implicit config: CacheConfig): scalacache.Cache[V] = CaffeineCache(underlying.asInstanceOf[com.github.benmanes.caffeine.cache.Cache[String, E
ntry[V]]])
caffeineCache: [V](implicit config: scalacache.CacheConfig)scalacache.Cache[V]

scala> import scalacache.modes.sync._
import scalacache.modes.sync._

scala> sync.put("hello")("world", ttl = None)
res1: Any = ()

scala> sync.get[String]("hello").get
res2: String = world

scala> sync.put("hi")(123, ttl = None)
res3: Any = ()

scala> sync.get[Int]("hi").get
res4: Int = 123

Corollory: why not Cache[F[_]]?

I don't think there's a good reason to restrict a given Cache[V] to only
support operations in some fixed effect F[_].
That's why I put the F[_] on the methods, not on the class. It just provides
a bit more flexibility, e.g. to use different effects in different parts of your
program.
About cats-effect

I've always tried to keep the number of dependencies as low as possible, and
adding a dependency on cats-effect would be a huge step that I'm not too keen
on. For a start, some users with Scalaz dependencies don't want to bring in a
transitive Cats dependency, and vice versa. The strategy for ScalaCache has
always been to keep the core almost dependency-free and have separate modules
for Cats, Scalaz, Circe, etc.
Of course, if I were copying huge swathes of cats-effect into my own library
just for the sake of avoiding a dependency, that would be crazy, but at the
moment that is not the case. It's just a few simple type classes.
There is another reason why I wrote my own versions of the cats-effect type
class hierarchy. It's actually subtly different in one place: handleNonFatal
in MonadError takes its argument lazily. This is so we can do some shady
unlawful stuff to provide an instance of MonadError (and Async) for Id.
Cats and cats-effect don't do this because in general it doesn't make any sense,
but it works for ScalaCache's limited use case.
About scodec

As above, I would be wary of adding a dependency like this to core unless it
is justified.