Re: Distinguishing case class members

On 26.12.2015 11:22, Peter Empen wrote:
> Currently all parameters of the first parameter list go into the 
> generated equals/hashCode/copy/unapply**methods.
> This works well for most cases but sometimes we need to /exclude/ some 
> parameters from equals/hashCode while keeping them copy and matchable.
>
> Now, to relieve programmers from the burden of defining custom 
> equals/hashCode in such situations, it would be great to have some 
> direct means to advise the compiler which parameters should /not /go 
> into equals/hashCode.
>
> One approach could be to provide a specific member-level annotation 
> for this purpose.
> Another approach could be to let val-/non-implicit-members of any 
> secondary parameter list become a parameter of copy automatically.
> Maybe you have even a better approach.
>
> What do you think about this proposal?
Write a macro for it. Way easier than hacking the compiler.
> -- 
> 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] 
> <mailto:[email protected]>.
> For more options, visit https://groups.google.com/d/optout.

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