Re: Sealed trait hierarchies and downcasting
Stephen Compall <[email protected]>
| Newsgroups | gmane.comp.lang.scala |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 2015-03-02 at 07:32 -0800, rklaehn wrote:
> 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 }
> }
For this purpose, I suggest replacing class Tree with
private implicit final class Tree(val _self: Foo) extends AnyVal {
def size:Int = _self match { case Leaf(_) => 1; case Branch(l, r) => l.size + r.size }
}
This avoids boxing and permits you to introduce helpers, without the
danger you note of accidentally introducing public methods in Foo.
Frankly, though, I have to wonder why you want OO-style methods at all,
at this point. You seem to be following the [entirely sensible and
advantageous] design style of the F# standard library, providing
functions to operate on data structures (e.g. List), even though member
methods are available as a design feature.
--
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.
signature.asc
(application/pgp-signature, 181 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlT1JrQACgkQYWjD35Pp0wLMMQCgphpHaLSaL83xS8Qcw4frNT7K nSIAoL06YOan3H6dNbsUXUDFgCgYkjxk =RgyM -----END PGP SIGNATURE-----