How about a "case trait"?

[Owen]

Where

 

case trait A

would desugar to

trait A extends Product with Serializable

This would mitigate the problem of Scala inferring a superfluous "Product with Serializable" for the result of methods that return case classes, for example Left and Right.

[ARKBAN]

+1 if it gives you .copy() for the common fields... although that might require a definition something like this:

case trait A( field: String, ... )

ARKBAN

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

[Daniel Armak]

You would need a cooperation protocol for equals/hashCode and copy() when several such case traits, and maybe a case class, are mixed together.

Daniel Armak

On Tue, Oct 11, 2016 at 8:05 PM, ARKBAN <ark...@arkban.net> wrote:

+1 if it gives you .copy() for the common fields... although that might require a definition something like this:

case trait A( field: String, ... )

ARKBAN

On 10/11/16 1:01 PM, Owen wrote:

Where

 

case trait A

would desugar to

trait A extends Product with Serializable

This would mitigate the problem of Scala inferring a superfluous "Product with Serializable" for the result of methods that return case classes, for example Left and Right.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe@googlegroups.com.