--
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 scala-languag...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Write a macro for it. Way easier than hacking the compiler.
Seth,
In my experience Scala users opt for case classes more often that for simple classes. Some of them not even consider pure classes. Most of them go for case classes even if just one of the case class extensions like ‘apply’ is ‘needed’. Further, nothing new for you, some wide-spread Scala libraries, like serialization libraries, also encourage the usage of case classes by providing special support for them.
Given this situation, a discussion about more maturity for case classes deserves some interest, at least I hope so.
I don’t see opinions like ‘The less flexibility it offers, the more I know what I'm getting’ are always valid arguments. If they were, one could for example ask whether optional ‘val’s in primary constructor parameter lists were also against simplicity. Further, don’t default ‘val’s in case class constructors, as opposed to non-default with all other templates, break simplicity? Yes they do for a good reason: usability.
But let’s get back to my original suggestion.
The reason I’m asking to make thoughts about additional flexibility for case classes on this list is that the compiler has all information about how to add that case class goodies, anyway. So why should the programmer be expected to use experimental macros or to inflate her case classes with otherwise boilerplate code if the compiler could do it easily? Maybe that’s also the reason why you had ‘mixed feelings’ one time or another.
You are asking for my use case. One use case for my suggestion are those thousands of case classes in enterprise apps that are just case classes because the developers like to instantiate them without spelling out ‘new’. Though less frequently, they also like pattern matching against them and, even less frequently, to call ‘copy’ for a new instance with a minor difference to the origin.
Now imagine at least 10 percent of the case classes finding their way into a Set or Map sooner or later. Another 10 percent go into equality based comparisons. Until then, it was fine to place all members into a single parameter list, 5 to 15 members on average. But usually just one of these members is a key - for instance, think of case classes reflecting database objects. At this point you are simply locked.
IMO a clean language design should really take care of both kinds of case class members: Those that go into apply/unapply/copy… and those, a subset of the first, that additionally go into equals/hashCode and not lump them together. (Those to be ignored in the generated methods are already covered by additional parameter lists.)
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?
--
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?
--
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 scala-languag...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
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 scala-languag...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Why are mutable case classes bad?Hello,