Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p><strong>First approach:</strong> -- insufficient according to OP --</p> <p>This will do, assuming that a single implementation of <code>foo</code> suits all classes in your hierarchy:</p> <pre><code>sealed abstract class A case class B() extends A case class C() extends A class RichA(a: A) { def foo() { println(this.a.getClass.getSimpleName) } } implicit def a2RichA(a: A): RichA = new RichA(a) (new C).foo() /* anon$1$C */ </code></pre> <p><br/> <strong>Second approach:</strong> -- lacks dynamic dispatch --</p> <p>My second approach has been inspired by the internals of the <a href="http://www.artima.com/scalazine/articles/scala_collections_architecture.html" rel="nofollow">Scala collection library</a>. However, it lacks dynamic dispatch, so it still not solve your problem.</p> <pre><code>sealed abstract class A case class B() extends A case class C() extends A abstract class RichA(a: A) { def foo(): Unit } class RichB(b: B) extends RichA(b) { def foo() { println("Doing B-specific stuff") } } class RichC(c: C) extends RichA(c) { def foo() { println("Doing C-specific stuff") } } sealed trait RichBuilder[T &lt;: A] { def apply(t: T): RichA } implicit object RichB extends RichBuilder[B] { def apply(b: B) = new RichB(b) } implicit object RichC extends RichBuilder[C] { def apply(c: C) = new RichC(c) } implicit def a2RichA[T &lt;: A](t: T) (implicit rb: RichBuilder[T]) : RichA = { rb(t) } (new B).foo() /* B-specific */ (new C).foo() /* C-specific */ // (new C).asInstanceOf[A].foo() /* ERROR: Can't find an implicit */ </code></pre> <p><br/> <strong>Claims:</strong></p> <p>If you want behaviour that depends on the runtime type of an objects, there are two possibilities I can see:</p> <ol> <li>Pattern matching</li> <li>Dynamic dispatch</li> </ol> <p>Pattern matching, as used in your original code, seems to lead to a situation where you have one place in the code where the matching is performed. Hence, extensions of your class hierarchy entail changes to that place - which might not be possible, e.g., if the hierarchy is extended by clients.</p> <p>Dynamic dispatch does not suffer from this disadvantage, which is could be the reason for why this approach is used in the Scala collection (it is briefly mentioned in the article). So you could try to use double dispatch (cf. the <a href="http://en.wikipedia.org/wiki/Visitor_pattern" rel="nofollow">visitor pattern</a>) However, this has the disadvantage that base class <code>A</code> must already declare a corresponding method - which somewhat defeats the goal of the Pimp My Library Pattern. Scala 2.10s new <a href="http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/library/index.html#scala.Dynamic" rel="nofollow">Dynamic</a> feature might be of help here, but due to missing experience I can't comment on that.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload