Re: Sealed trait hierarchies and downcasting

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`.

-- 
Stephen Compall
"^aCollection allSatisfy: [:each|aCondition]": less is better

-- 
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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEABECAAYFAlT0V5wACgkQYWjD35Pp0wJAeACeKOL27I8t/DxJo2beZanXopI2
CKgAnjK01yXLg0yOBlFGnOYgDFp/drpK
=jzAk
-----END PGP SIGNATURE-----