Re: Distinguishing case class members

We all like `case class` in Scala because it avoids boilerplate, but 
there's another enormous reason to like it: it tells the reader of your 
code what to expect.

You propose adding more flexibility to `case class`. If anything, I feel 
like `case class` already offers too much flexibility, and I would prefer 
it offered less! The less flexibility it offers, the more I know what I'm 
getting when I'm reading somebody else's code and I see `case class`.

Admittedly, the flexibility you want is already available by manually 
overriding `equals` and `hashCode`. So you might argue that your proposal 
doesn't actually add flexibility, but merely reduce boilerplate. But I'm 
not sure it's desirable to reduce boilerplate for something that I'd rather 
not see in Scala code at all. Or at least, hardly ever.

I admit to having occasionally — with mixed feelings — used the ability to 
exclude parameters from equals/hashCode/toString participation by putting 
them in a case class's parameter list. Isn't that enough? Do we really need 
more flavors of this? Can you explain your use case?

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