Re: Distinguishing case class members

 

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

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