Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Pattern matching structural types in Scala

Tags:

Why does this print wtf? Does pattern matching not work on structural types?

  "hello" match {     case s: { def doesNotExist(i: Int, x: List[_]): Double } => println("wtf?")     case _ => println("okie dokie")   } 
like image 833
Mitch Blevins Avatar asked Jan 01 '10 08:01

Mitch Blevins


People also ask

Does Scala have pattern matching?

Notes. Scala's pattern matching statement is most useful for matching on algebraic types expressed via case classes. Scala also allows the definition of patterns independently of case classes, using unapply methods in extractor objects.

What are the different ways to implement match expressions in scala?

Using if expressions in case statements First, another example of how to match ranges of numbers: i match { case a if 0 to 9 contains a => println("0-9 range: " + a) case b if 10 to 19 contains b => println("10-19 range: " + b) case c if 20 to 29 contains c => println("20-29 range: " + c) case _ => println("Hmmm...") }

What is case class and pattern matching in Scala?

It is defined in Scala's root class Any and therefore is available for all objects. The match method takes a number of cases as an argument. Each alternative takes a pattern and one or more expressions that will be performed if the pattern matches. A symbol => is used to separate the pattern from the expressions.

Which method of case class allows using objects in pattern matching?

Case classes are Scala's way to allow pattern matching on objects without requiring a large amount of boilerplate. In the common case, all you need to do is add a single case keyword to each class that you want to be pattern matchable.


1 Answers

Running this example in the Scala interpreter with unchecked warnings on (scala -unchecked) produces the following warning: warning: refinement AnyRef{def doesNotExist(Int,List[_]): Double} in type pattern is unchecked since it is eliminated by erasure. Unfortunately, a generic type like this cannot be checked at runtime as the JVM doesn't have reified generics.

All that the JVM sees in this pattern match is:

"hello" match {   case s: Object => ...    case annon: Object => ... } 

EDIT: In response to your comments, I have been thinking about a solution but didn't have the time to post it yesterday. Unfortunately, even if it should work, the compiler fails to inject the proper Manifest.

The problem you want to solve is to compare if an object is of a given structural type. Here's some code I've been thinking of (Scala 2.8-r20019, as Scala 2.7.6.final crashed on me a couple of times while playing with similar ideas)

type Foo = AnyRef { def doesNotExist(i: Int, x: List[_]): Double }  def getManifest[T](implicit m: Manifest[T]) = m  def isFoo[T](x: T)(implicit mt: Manifest[T]) =    mt == getManifest[Foo] 

Method isFoo basically compares the manifests of the class x of Foo. In an ideal world, the manifest of a structural type should be equal to the manifest of any type containing the required methods. At least that's my train of thought. Unfortunately this fails to compile, as the compiler injects a Manifest[AnyRef] instead of a Manifest[Foo] when calling getManifest[Foo]. Interestingly enough, if you don't use a structural type (for example, type Foo = String), this code compiles and works as expected. I'll post a question at some point to see why this fails with structural types -- is it a design decision, or it is just a problem of the experimental reflection API.

Failing that, you could always use Java reflection to see if an object contains a method.

def containsMethod(x: AnyRef, name: String, params: java.lang.Class[_]*) = {   try {      x.getClass.getMethod(name, params: _*)     true     }   catch {     case _ =>  false   } } 

which works as expected:

containsMethod("foo", "concat", classOf[String]) // true containsMethod("foo", "bar", classOf[List[Int]]) // false 

... but it's not very nice.

Also, note that the structure of a structural type is not available at runtime. If you have a method def foo(x: {def foo: Int}) = x.foo, after erasure you get def foo(x: Object) = [some reflection invoking foo on x], the type information being lost. That's why reflection is used in the first place, as you have to invoke a method on an Object and the JVM doesn't know if the Object has that method.

like image 155
Flaviu Cipcigan Avatar answered Oct 07 '22 11:10

Flaviu Cipcigan