Use case and examples for type pattern with type variable

后端 未结 1 1772
一个人的身影
一个人的身影 2020-12-06 02:09

I found out reading the spec that scala supports binding type variables when doing a type pattern match:

Map(1 -> \"one\", 2 -> \"two\") match {
  case         


        
1条回答
  •  有刺的猬
    2020-12-06 02:22

    I hope this won't get too long, but I seriously doubt it, that's why I'm gonna try to provide a quick answer first: "When you name (abstract) something, the main use case is referring to it later". Well that wasn't helpful now, was it?

    Consider this simple Scala function:

    val sum = (a: Int, b: Int) => a + b
    

    The compiler does not need to know that a is an a and b is a b. All it needs to know that a as well as b are of type Int and that a comes before b (which wouldn't matter in this case since addition is commutative, but the compiler cares anyway!). Scala offers a (don't get me wrong I also love it) compiler friendly placeholder syntax, which acts as a proof of this "hypothesis".

    val sum: (Int, Int) => Int = _ + _ // where the 1st _ differs from the 2nd _
    

    Now take a look at this:

    case x: SomeTypeParameterizedWith[AnotherType] // AnotherType is erased anyway
    case x: SomeParameterizedType[_] // Existential type
    case x: SomeParameterizedType[kind] // Existential type which you can reference
    

    When you don't care about the type argument use the placeholder syntax. When you do (for whatever reason) care you should name the type argument with a lower case so the compiler knows you want to treat it as an identifier.

    Back to your question.

    The primary use for existential types is working around Java's wildcard types. This is taken from Programming in Scala - Existential Types and was slightly modified by yours truly.

    // This is a Java class with wildcards
    public class Wild {
      public java.util.Collection contents() {
        java.util.Collection stuff = new Vector();
        stuff.add("a");
        stuff.add("b");
        stuff.add("see");
        return stuff;
      }
    }
    
    // This is the problem
    import scala.collection.mutable.Set
    val iter = (new Wild).contents.iterator
    val set = Set.empty[???] // what type goes here?
    while (iter.hasMore)
      set += iter.next()
    
    // This is the solution
    def javaSet2ScalaSet[T](jset: java.util.Collection[T]): Set[T] = {
      val sset = Set.empty[T] // now T can be named!
      val iter = jset.iterator
      while (iter.hasNext)
        sset += iter.next()
      sset
    }
    

    Ok, so what just happened? Simple generics, no magic there?! If you are dealing with generics on a day to day basis this looks normal to you, but you are forgetting, that the ultra super concept of introducing type arguments into scope works only on classes and methods. What if you are outside of a class or a method, just in some random scope in the middle of nowhere (like REPL)? Or what if you are in a class or a method but the type arguments have not been introduced into their scopes? This is where your question and this answer come in play.

    val set = new Wild().contents match {
      case jset: java.util.Collection[kind] => {
        val sset = Set.empty[kind]
        val iter = jset.iterator
        while (iter.hasNext)
          sset += iter.next()
        sset
      }
    }
    

    The identifier kind is required so the compiler can verify that you are referring to the same thing.

    Note, that you can't just add strings into the set since the type of the set is Set[_].

    0 讨论(0)
提交回复
热议问题