Hacker News Reader

Comment by VLM | Hacker News Reader

This will be an interesting side effect: "omit generation of unapply"

Yes, this means there won't be a 1-to-1 conversion between a case class and a tuple anymore, since tuples are still limited to 22. This will probably break a few things out there (for people crazy enough to use case classes with 23+ parameters).

I think the only place I've seen anyone wanting more than 22 parameters was people who had a database table with more than 22 rows (!) and where using the SLICK library.

So basically, anyone with a legacy database :)

Yeah we ran into this problem... Scala and the whole ecosystem can get annoying. In the real world, outside of the academic bubble that Scala lives in, database tables are over 22 columns.

In Scala I find it more natural to group multiple columns together / break the case-class representing the table into multiple case-classes. The problem is that Slick needs to serialize/deserialize those case-classes into tuples.

I think the arity limit is more or less planned to be fixed in Scala > 2.11 anyway.

Seems to be fixed in v2.0: http://slick.typesafe.com/news/2014/01/21/slick-2.0.0-releas...

You can also run into it with forms in play, although for a variety of reasons you hit it at 18.

The whole situation just drips with arrogance... "we have a magic number, and if you hit it, you suck"

I agree. I know people posted a comment saying its fixed in 2.11 but if Scala wants to be production ready language it shouldn't take 10 years to address this.

> "we have a magic number, and if you hit it, you suck"

You mean like Java does since ... forever?

The problem is the real world doesn't always leave you with a choice. If you need to interface with a database that's got a table with 43 columns, good luck using Slick. Need to serialize it to JSON? Play-Json isn't going to like that.

I'm very much looking forward to fixing this ridiculous situation. Onboarding a new hire to Scala with this being the first thing they run in to isn't pretty.

It's a problem that I contemplate every day. More often than not I have to resolve to using Map in which case I have to use external JSON library, because like you mentioned - Play JSON is not that friendly with anything else than case class.

We've resorted to an ugly nested case class structure. We like Play-Json overall, it works well even with large (>100mb) JSON objects, but we'd love to not deal with that. TBH, it's a bigger problem with Slick where you we can't just mess with the schema since other systems use the same DB.

"We've resorted to an ugly nested case class structure."

Yes the same here, and I haven't found an idea that's overall better, taking everything into account.

Have to agree.. I ran into this when on the first time using Scala ,when I thought it would be fun to learn the language and a framework at the same time (Play). After initial crying for a bit I gave up trying to reason why this limit was put in place and just nested my data structure.

Reply on news.ycombinator.com