Re: Distinguishing case class members

Haoyi Li <[email protected]> Wed, 13 Jan 2016 16:28:35 -0800
Newsgroups gmane.comp.lang.scala
Message-ID <CALruUQ+kUKDER9L39s=K4-n_F6Dr=OHjB7W0ZM-3Nq=bRrJLpg@mail.gmail.com>
I disagree, x == y changing over time makes perfect sense to me. If I have
two empty buffers, they're equal. I add something to one of them, they're
unequal. I add that thing to the other, they're equal again.

Sure, it makes sets and dictionaries unhappy if you put these mutable
structs into them, but if you don't do that equality works great. If it's
already mutable anyway, you've already broken all your referential
transparency functional programming stuff, but there is no "additional
badness" from having == also be mutable

On Wed, Jan 13, 2016 at 3:50 PM, Sébastien Doeraene <[email protected]>
wrote:

> Hi,
>
> Because it is usually a bad thing for `x == y` to change over time. If
> your case class is mutable, its auto-generated `equals` will cause `x == y`
> to to behave differently during the life of `x` and/or `y`. Mutable classes
> should always have reference equality, i.e., `x == y` if and only if `x eq
> y`, otherwise you break referential transparency, one of the most useful
> properties of functional programming.
>
> Cheers,
> Sébastien
>
> On Wed, Jan 13, 2016 at 11:50 PM, Oliver Ruebenacker <[email protected]>
> wrote:
>
>>
>>      Hello,
>>
>>   Why are mutable case classes bad?
>>
>>      Best, Oliver
>>
>> On Wed, Jan 13, 2016 at 5:22 PM, Seth Tisue <[email protected]> wrote:
>>
>>> in this vein, see also Rüdiger Klaehn's answer at
>>> http://stackoverflow.com/a/34719624/86485 ("People frequently use case
>>> classes and then try to customize/abuse them to do something else than what
>>> case classes are supposed to do...")
>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> --
>> Oliver Ruebenacker
>> Senior Software Engineer, Diabetes Portal
>> <http://www.type2diabetesgenetics.org/>, Broad Institute
>> <http://www.broadinstitute.org/>
>>
>> --
>> 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.