Jan Kotek:
I understand practical reasons behind having only 22 tuples (code readability etc). But why there is limit for 22 fields on case class? It is like limitation from 30 years old Fortran.
You may say that case class with 22 fields is monster and I should not use it. It is not true. I use default values and copy method. It is well readable and more efficient than property map.
I think case matching on such big classes is not important. You may simply make compilaton exception.
But Scalac should still generate copy method and named arguments."
Klang:
Traditionally, if you need more than 21 fields in the constructor, you should probably rethink your design.
Paul:
BTW I agree with you, there's no good reason we should have a hard arity limit jump out and grab you like that. Alex's suggestion of a slow path for higher arities sounds eminently plausible to me. If martin would let my literally dependent types patch in we could probably even do it in the type system at the user level, because you could parameterize the container on 52.type or whatever since the arity is known statically.
Odersky:
There are a lot of good arguments to add stuff to case classes or to add optional case-class like functionality to normal classes, driven by compiler plugins and annotations. Putting some of these things into place would be a good start. In the medium term, however, we should look for a more systematic solution to the problem. I have a hunch that such a solution could be based on a more complete reflection system and manifests. The SYB (scrap your boilerplate) papers in the Haskell domain have shown how to do things like deriving clauses for algebraic datatypes with manifests, for instance.
dpp
FWIW, I've turned at least 1 protocol into case classes and have had to work around the 22 field limit. This was the case where the protocol had many many optional parameters/attributes.
Rose Toomey:
Nope. You're limited to 22 parameters in a case class right now.
However, if you just want to turn a Map[String, Any] to JSON and you don't care about being able to deserialize it back to a model object, I just added that ability to 1.9.2-SNAPSHOT.
Many frameworks are using case casses as data holder classes for JSON or SQL tables.I have such a JSON object with more than 30 fields and I found out that there is a hard limit to 22 fields for case classes. To spilt it up into 2 (or more) case classes would not be very convenient.
Lars Hupel
The best "workaround" for that is to use heterogeneous lists as described in [1]. Try to read the other posts of the series on HLists, too.
Scala's tuple/case class limits should be referred to as "Catch 22" henceforth. Thank you.