twitter / storehaus

Storehaus is a library that makes it easy to work with asynchronous key value stores
Apache License 2.0
464 stars 86 forks source link

Reasoning behing the Readable/WritableStore trait type parameters #268

Closed AndreiBarsan closed 9 years ago

AndreiBarsan commented 9 years ago

I feel a bit confused by the type constraints in the ReadableStore (or its WritableStore sibling) definitions:

trait ReadableStore[-K, +V] extends Closeable {
  def get(k: K): Future[Option[V]]
  def multiGet[K1 <: K](ks: Set[K1]): Map[K1, Future[Option[V]]]
  override def close(time: Time) = Future.Unit
}

Why is multiGet parameterized by allowing any subtype of K to also be used as a parameter, while get isn't? (Sorry if the answer is obvious--I'm still learning Scala and getting to grips with its wonderful type system!)

rubanm commented 9 years ago

K is invariant in Set, but Store defines it as contravariant. So this is a way to decouple the two and let the compiler know that.

This is a good slidedeck I think: http://www.slideshare.net/dgalichet/demystifying-scala-type-system

AndreiBarsan commented 9 years ago

I see. Thanks for the info! I was actually under the impression that the Set's type parameter was actually covariant, like List's. This StackOverflow question actually cleared that misconception up: http://stackoverflow.com/questions/676615/why-is-scalas-immutable-set-not-covariant-in-its-type