title: Accounting for type parameters in a Scala generic class 'equals' method... are manifests the only way?
body: <p>Given a simple generic class:</p>
  
  <pre><code>class EqualsQuestion[T]( val value :T )
  </code></pre>
  
  <p>it seems reasonable that the following code would resolve to "false":</p>
  
  <pre><code>val a = new EqualsQuestion[Int]( 5 )
  val b = new EqualsQuestion[Long]( 5 )
  a == b
  </code></pre>
  
  <p>(Yes, it's a contrived example.  In my real code I wanted '==' to fail if the type parameters are different, regardless if the values are the same, though at this point I'm not sure that makes sense.  Still, it struck me as an interesting Scala question to puzzle through.)</p>
  
  <p>Anyway, I of course haven't been able to implement such an equals() method:</p>
  
  <pre><code>override def equals( obj :Any ) :Boolean = 
  {
      obj match {
          case that :EqualsQuestion[T] =&gt; 
                  ( this.getClass == that.getClass ) &amp;&amp;  // no help
                  this.getClass().isInstance(that) &amp;&amp; // no help
                  //this.value.getClass == that.value.getClass &amp;&amp; // doesn't even compile
                  this.value == that.value
  
          case _ =&gt; false
      }
  }
  </code></pre>
  
  <p>The issue is type erasure, I know:  all the compiler knows at this point is that 'T' is a type, but it has no idea what that type is.  So it can't make comparisons.</p>
  
  <p>It seems 2.8 can address this with manifests, but... I'm not quite to point of grokking <a href="https://stackoverflow.com/questions/1094173/how-do-i-get-around-type-erasure-on-scala-or-why-cant-i-get-the-type-parameter">How do I get around type erasure on Scala? Or, why can&#39;t I get the type parameter of my collections?</a>.  </p>
  
  <p>Any other ways around this?</p>