Re: Distinguishing case class members

Or move the parameters which shouldn't affect equals into a different
parameter list, and simulate the original param lists with extra
constructors.

Daniel Armak

On Sat, Dec 26, 2015 at 4:49 PM, Simon Schäfer <[email protected]> wrote:

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

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