Re: Sealed trait hierarchies and downcasting

Am Montag, 2. März 2015 13:29:21 UTC+1 schrieb Stephen Compall:
>
> On Mon, 2015-03-02 at 11:10 +0100, Rüdiger Klaehn wrote: 
> > sealed trait Foo 
> > 
> > object Foo { 
> > 
> >   def empty: Foo = ... 
> > 
> >   def apply(...): Foo = ... 
> > 
> >   private sealed trait Tree extends Foo 
> > 
> >   private case class Leaf(...) extends Tree 
> > 
> >   private case class Branch(...) extends Tree 
> > } 
> > 
> > Basically have a sealed trait or sealed abstract class for the public 
> > interface, and then a completely 
> > private hierarchy that is the only implementation. This is a nice way 
> > to hide implementation details while still not having the overhead of 
> > boxing or the annoyance of wrapping in a value class. 
> > 
> > However, a problem with this approach is that the compiler does not 
> > seem to know that a Foo must always be a Tree. 
>
> I don't see how you would lose any of the benefits you stated if `Tree` 
> simply wasn't included at all.  You would remove no overhead and reveal 
> no implementation details by eliminating `Tree`. 
>
>
I want Foo to be a pure trait / interface, and not have any implementation 
there. Tree will contain implementation and private helper methods. E.g.

sealed trait Foo { def size: Int }

private sealed class Tree extends Foo {
  final def size:Int = this match { case Leaf(_) => 1; case Branch(l, r) => 
l.size + r.size }
}

I think this is preferable to code where the implementation has to be 
carefully hidden by hiding all helper methods. With the latter, it is very 
easy to accidentally introduce a public method. With a separate trait, this 
is almost impossible.

-- 
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.