Re: Distinguishing case class members

     Hello,

  If a field is used for apply/unapply, but not for equals/hashCode, you
would have objects that are equal but don't match the same patterns.
Doesn't that sound really awefull?

  e.g.

  case class A(x: Int, @DoNotUseForEquals y: Int)  // not real code

  val a1 = A(1, 2)
  val a2 = A(1, 3)  //  a1 == a2

  a2 match {
    case A(_, 2) => println("y is 2")  //  matches a1, but not a2
    case _ => println("y is not 2")
  }

     Best, Oliver

On Wed, Jan 13, 2016 at 10:56 AM, Justin du coeur <[email protected]>
wrote:

> On Sun, Jan 10, 2016 at 8:12 AM, Matt Farmer <[email protected]> wrote:
>
>> I’m concerned that the rarity of needing to do this may make it
>> unreasonable to maintain such a feature. I’ve been doing Scala since 2011
>> and have maybe needed to do that once? How frequently do you find yourself
>> wanting this?
>>
>
> Yeah, agreed -- in about five years of full-time Scala, and very heavy use
> of case classes, I don't think I've ever wanted this particular feature.
> It seems like a rare edge case to me, and not a necessarily desireable one.
>
> And to Seth's point -- I think we have a real problem, as a community,
> that there's never been a clear, universally-accepted statement of what
> case classes are *for*.
>
> -- Do they exist for the "case" concept, making unapply cheap and easy?
> -- Are they just the sum of the functionality, a way to get apply, equals
> and hashCode for free?
> -- Or are they a signal that this class is immutable, and that all that
> functionality makes sense *because* this is an immutable class described by
> its parameters?
>
> Personally, I subscribe to the third of those; from what he's said, I
> suspect Seth is coming from a similar viewpoint.  I think of the
> functionality of case classes as directly derived from the notion that this
> object is precisely described by its immutable parameters -- that's the
> mental model, and the driver of how it works.  When I see a case class, I
> *expect* it to be immutable, and I *expect* all of its parameters to factor
> into equals.  It's possible to violate those expectations, but that's a
> recipe for bugs.
>
> Sadly, the horse has *long* since bolted the barn on this one: "impure"
> case classes are, in practice, pretty common.  But I don't think they
> should be driving our thinking.  I agree with what I think Seth is saying
> here: with 20/20 hindsight, it's actually a bit of a language design bug
> that case classes are more flexible than they ought to be, because that
> impedes reasoning about them easily.  We shouldn't encourage that...
>
> --
> 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.