22 fields limit in case classes

Traditionally, if you need more than 21 fields in the constructor, you should probably rethink your design.

On Fri, Oct 15, 2010 at 2:31 PM, Jan Kotek <opencoeli [at] gmail [dot] com> wrote:

Hi,

I have question about 22 fields limit on case classes.

I use case class to store configuration. It is way better than using
Map, mostly because I get static typing. Now as my classes grown, I
hit strange internal error from Scalac. By google I found there is
limit of 22 fields on case class. See this thread:

http://stackoverflow.com/questions/2226305/managing-flexible-typed-immutable-data-structures-in-scala-in-2-8-x

It is related to 22 tuples limit. Tuples classes are generated by
'genprod.scala'  and only solution is to increase  limit and compile
my own version of Scala Library.

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.

So is there a chance for lifting number of tuples to bigger number.
For example 64?

Regards,
Jan Kotek

--
Viktor Klang,
Code Connoisseur
Work:   www.akkasource.com
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

With over 22 fields, it's almost guaranteed that there will be certain natural grouping between them, allowing you to use nested case classes.
If you're *that* concerned over the performance of the copy method, then you'll also be pleased to hear that this approach is more efficient as well.


On 15 October 2010 13:34, √iktor Klang <viktor [dot] klang [at] gmail [dot] com> wrote:

Traditionally, if you need more than 21 fields in the constructor, you should probably rethink your design.

On Fri, Oct 15, 2010 at 2:31 PM, Jan Kotek <opencoeli [at] gmail [dot] com> wrote:

Hi,

I have question about 22 fields limit on case classes.

I use case class to store configuration. It is way better than using
Map, mostly because I get static typing. Now as my classes grown, I
hit strange internal error from Scalac. By google I found there is
limit of 22 fields on case class. See this thread:

http://stackoverflow.com/questions/2226305/managing-flexible-typed-immutable-data-structures-in-scala-in-2-8-x

It is related to 22 tuples limit. Tuples classes are generated by
'genprod.scala'  and only solution is to increase  limit and compile
my own version of Scala Library.

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.

So is there a chance for lifting number of tuples to bigger number.
For example 64?

Regards,
Jan Kotek

--
Viktor Klang,
Code Connoisseur
Work:   www.akkasource.com
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

--
Kevin Wright

mail / gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com
pulse / skype: kev.lee.wright
twitter: @thecoda

Hi,

>Traditionally, if you need more than 21 fields in the constructor, you should probably rethink your design.

Scala 2.8 have parameter names and default values. So I dont have to
use all of those 22 fields. For example my class looks like:

case class Config( x:Double = 10, y:Double = 10,
width:Double = 1, height:Double = 1,
//snip 20 more fields
)

val config = new Config(height=2) //there is no 22 fields in constructor !!!

val config2 = config.copy(x=100, y=100) //again, no 22 fields in copy method

> With over 22 fields, it's almost guaranteed that there will be certain natural grouping between them, allowing you to use nested case classes.

I prefer not to use it. I found single class for configuration easier.
It is similar argument like 'dont use class name longer than 22
characters'.

> If you're *that* concerned over the performance of the copy method, then you'll also be pleased to hear that this approach is more efficient as well.

I dont care about performance of copy method.

J.

You're going quite far outside the typical use-case for case classes here, which is basically as a data type with equals(), toString(), and pattern-matching capability.There's a trade-off here: Make them too big, and the compiler struggles with JVM limits when generating pattern-match code.
All you really need is a regular (non-case) class, implementing the copy method by hand is simple enough (if a bit heavy on the boilerplate).Something like `Config` sounds like it'll be a one-off, so this shouldn't be too painful.





On 15 October 2010 14:16, Jan Kotek <opencoeli [at] gmail [dot] com> wrote:

Hi,

>Traditionally, if you need more than 21 fields in the constructor, you should probably rethink your design.

Scala 2.8 have parameter names and default values. So I dont have to
use all of those 22 fields. For example my class looks like:

case class Config( x:Double = 10, y:Double = 10,
width:Double = 1, height:Double = 1,
  //snip 20 more fields
)

val config = new Config(height=2)  //there is no 22 fields in constructor !!!

val config2 = config.copy(x=100, y=100) //again, no 22 fields in copy method


> With over 22 fields, it's almost guaranteed that there will be certain natural grouping between them, allowing you to use nested case classes.

I prefer not to use it. I found single class for configuration easier.
It is similar argument like 'dont use class name longer than 22
characters'.

> If you're *that* concerned over the performance of the copy method, then you'll also be pleased to hear that this approach is more efficient as well.

I dont care about performance of copy method.

J.

--
Kevin Wright

mail / gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com
pulse / skype: kev.lee.wright
twitter: @thecoda

On Fri, Oct 15, 2010 at 6:59 AM, Kevin Wright <kev [dot] lee [dot] wright [at] gmail [dot] com> wrote:

You're going quite far outside the typical use-case for case classes here, which is basically as a data type with equals(), toString(), and pattern-matching capability.

Is it worth discussing a "slow path" for Product[n > 21] that would use a different implementation strategy (e.g. collection of Products...) but still produce a comparable external interface?
-0xe1a

On Fri, Oct 15, 2010 at 01:31:18PM +0100, Jan Kotek wrote:
> You may say that case class with 22 fields is monster and I should not
> use it.

I wouldn't say that, but I did want to quote it because I love it. I
say case class with 22 fields is MONSTER!

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.

On Fri, Oct 15, 2010 at 12:38 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:

On Fri, Oct 15, 2010 at 01:31:18PM +0100, Jan Kotek wrote:
> You may say that case class with 22 fields is monster and I should not
> use it.

I wouldn't say that, but I did want to quote it because I love it.  I
say case class with 22 fields is MONSTER!

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.

FWIW I agree it's a code smell to have 22 fields in a class *that you've written yourself*, but there are an awful lot of "meta" libraries sniffing around these days that rely on Product's product-ness for a lot of their magic, and 22 is insufficient by at least an order of magnitude to be confident that you can handle most clients' domains.
To take one example of a popular meta-problem domain, there are an awful lot of RDBMS tables in the world with more than 22 columns, and it would sure be nice to have exactly one (ultimate) row (super) type in a relational metamodel.  I haven't looked at squeryl or scala-query in nearly enough detail to see how/whether they address this, but I'm sure it's a pain point.
-0xe1a

On Fri, Oct 15, 2010 at 12:38 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:

On Fri, Oct 15, 2010 at 01:31:18PM +0100, Jan Kotek wrote:
> You may say that case class with 22 fields is monster and I should not
> use it.

I wouldn't say that, but I did want to quote it because I love it.  I
say case class with 22 fields is MONSTER!

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.

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.  Having a way that the limit is not their would be a win.
 

--
Paul Phillips      | It's better to have gloved and tossed than never to
Apatheist          | have played baseball.
Empiricist         |
slap pi uphill!    |----------* http://www.improving.org/paulp/ *----------

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics

On 2010-10-15 22:50, Alex Cruise wrote:
> To take one example of a popular meta-problem domain, there are an
> awful lot of RDBMS tables in the world with more than 22 columns, and
> it would sure be nice to have exactly one (ultimate) row (super) type
> in a relational metamodel. I haven't looked at squeryl or scala-query
> in nearly enough detail to see how/whether they address this, but I'm
> sure it's a pain point.

It is for some users. In the case of ScalaQuery, table definitions can
contain a separate scala.List of columns for creating the table (where
Scala type information is not needed) but projections (including a
table's default "*" projection) are limited to 22 columns because the
ProjectionXY classes mirror TupleXY. ParametersXY classes for parameter
lists of query templates (function-like queries with pre-computed SQL)
do not rely on FunctionXY because they are always tupled (and can still
be called with the same syntax thanks to Scala's automatic untupling),
but that, of course, means that they also run into the Tuple22 limit.
Both, ProjectionXY and ParametersXY classes are generated at
compile-time from FreeMarker templates.

HArrays or HLists might be an option for both (provided that Scala's
type inferencer could handle the additional complexity) but they
wouldn't allow the nice function call and result unpacking syntax
provided by tuples. An alternative suggestion that was recently brought
up on the ScalaQuery mailing list is to allow nested projections so that
the user of the API could manually group large numbers of columns into
multiple tuples.

-sz

Anyone for an HMap?

On 16 October 2010 11:37, Stefan Zeiger <szeiger [at] novocode [dot] com> wrote:

 On 2010-10-15 22:50, Alex Cruise wrote:

To take one example of a popular meta-problem domain, there are an awful lot of RDBMS tables in the world with more than 22 columns, and it would sure be nice to have exactly one (ultimate) row (super) type in a relational metamodel.  I haven't looked at squeryl or scala-query in nearly enough detail to see how/whether they address this, but I'm sure it's a pain point.

It is for some users. In the case of ScalaQuery, table definitions can contain a separate scala.List of columns for creating the table (where Scala type information is not needed) but projections (including a table's default "*" projection) are limited to 22 columns because the ProjectionXY classes mirror TupleXY. ParametersXY classes for parameter lists of query templates (function-like queries with pre-computed SQL) do not rely on FunctionXY because they are always tupled (and can still be called with the same syntax thanks to Scala's automatic untupling), but that, of course, means that they also run into the Tuple22 limit. Both, ProjectionXY and ParametersXY classes are generated at compile-time from FreeMarker templates.

HArrays or HLists might be an option for both (provided that Scala's type inferencer could handle the additional complexity) but they wouldn't allow the nice function call and result unpacking syntax provided by tuples. An alternative suggestion that was recently brought up on the ScalaQuery mailing list is to allow nested projections so that the user of the API could manually group large numbers of columns into multiple tuples.

-sz

--
Kevin Wright

mail / gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com
pulse / skype: kev.lee.wright
twitter: @thecoda

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

Jan

On Sat, Oct 16, 2010 at 11:39 AM, Kevin Wright wrote:
> Anyone for an HMap?
>
> On 16 October 2010 11:37, Stefan Zeiger wrote:
>>
>>  On 2010-10-15 22:50, Alex Cruise wrote:
>>>
>>> To take one example of a popular meta-problem domain, there are an awful
>>> lot of RDBMS tables in the world with more than 22 columns, and it would
>>> sure be nice to have exactly one (ultimate) row (super) type in a relational
>>> metamodel.  I haven't looked at squeryl or scala-query in nearly enough
>>> detail to see how/whether they address this, but I'm sure it's a pain point.
>>
>> It is for some users. In the case of ScalaQuery, table definitions can
>> contain a separate scala.List of columns for creating the table (where Scala
>> type information is not needed) but projections (including a table's default
>> "*" projection) are limited to 22 columns because the ProjectionXY classes
>> mirror TupleXY. ParametersXY classes for parameter lists of query templates
>> (function-like queries with pre-computed SQL) do not rely on FunctionXY
>> because they are always tupled (and can still be called with the same syntax
>> thanks to Scala's automatic untupling), but that, of course, means that they
>> also run into the Tuple22 limit. Both, ProjectionXY and ParametersXY classes
>> are generated at compile-time from FreeMarker templates.
>>
>> HArrays or HLists might be an option for both (provided that Scala's type
>> inferencer could handle the additional complexity) but they wouldn't allow
>> the nice function call and result unpacking syntax provided by tuples. An
>> alternative suggestion that was recently brought up on the ScalaQuery
>> mailing list is to allow nested projections so that the user of the API
>> could manually group large numbers of columns into multiple tuples.
>>
>> -sz
>
>
>
> --
> Kevin Wright
>
> mail / gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com
> pulse / skype: kev.lee.wright
> twitter: @thecoda
>
>

On 18/10/2010 10:36, Jan Kotek wrote:
> hi
> 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.

Intersting, so what we are seing here is a new[1] use case of case
classes, where "case classes" are not used for the case part, but as
immutable data structure with automatic equals, hashchode and copy method.

It's interesting, because it clearly splits the use cases for case
class, and (I believe) with two level of difficulty on the compiler:
1 - immutable data structures : simple at the compiler level, it's just
synthetising some methods. They are solelly a shortcut to define classes
with a *big* list of parameter. On class with such big list of
parameters, we don't want to do pattern matching on all parameters (it
will be completely unreadable), but prefer to define sensible extractors
on them, if needed;
2 - real case class, with the hard pattern matching part.

"1" was not really sensible before default and named parameter, but now,
it seems to be quite appropriate to match data structures protocol and
all other types of simple data containers.

Well, it's just a statement of fact, I don't know what to do with that,
but it seems that there is something.

[1] not exactly new, as it is one of the most used example when someone
wants to show to a Javaiste how much more concise Scala is. More a kind
of refined use case for what is provided today by case classes.

Therein lies the rub... This pattern didn't really exist before named/default parameters came along with 2.8, so we're exploring a whole new design space here.
I'm seriously tempted to knock up a compiler-plugin that can generate the copy method and mix-in the product trait, driven by the presence of an annotation on the class.  Given that it wouldn't need any type information from outside of the unit, this can all be done before the namer phase - so none of the usual issues with method synthesis should arise.

On 18 October 2010 11:12, Francois <fanf42 [at] gmail [dot] com> wrote:

On 18/10/2010 10:36, Jan Kotek wrote:

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

Intersting, so what we are seing here is a new[1] use case of case classes, where "case classes" are not used for the case part, but as immutable data structure with automatic equals, hashchode and copy method.

It's interesting, because it clearly splits the use cases for case class, and (I believe) with two level of difficulty on the compiler:
1 - immutable data structures : simple at the compiler level, it's just synthetising some methods. They are solelly a shortcut to define classes with a *big* list of parameter. On class with such big list of parameters, we don't want to do pattern matching on all parameters (it will be completely unreadable), but prefer to define sensible extractors on them, if needed;
2 - real case class, with the hard pattern matching part.

"1" was not really sensible before default and named parameter, but now, it seems to be quite appropriate to match data structures protocol and all other types of simple data containers.

Well, it's just a statement of fact, I don't know what to do with that, but it seems that there is something.

[1] not exactly new, as it is one of the most used example when someone wants to show to a Javaiste how much more concise Scala is. More a kind of refined use case for what is provided today by case classes.

On Mon, Oct 18, 2010 at 12:46 PM, Kevin Wright <kev [dot] lee [dot] wright [at] gmail [dot] com> wrote:

Therein lies the rub... This pattern didn't really exist before named/default parameters came along with 2.8, so we're exploring a whole new design space here.
I'm seriously tempted to knock up a compiler-plugin that can generate the copy method and mix-in the product trait, driven by the presence of an annotation on the class.  Given that it wouldn't need any type information from outside of the unit, this can all be done before the namer phase - so none of the usual issues with method synthesis should arise.

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.

Cheers

  -- Martin

 

On 18 October 2010 11:12, Francois <fanf42 [at] gmail [dot] com> wrote:

On 18/10/2010 10:36, Jan Kotek wrote:

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

Intersting, so what we are seing here is a new[1] use case of case classes, where "case classes" are not used for the case part, but as immutable data structure with automatic equals, hashchode and copy method.

It's interesting, because it clearly splits the use cases for case class, and (I believe) with two level of difficulty on the compiler:
1 - immutable data structures : simple at the compiler level, it's just synthetising some methods. They are solelly a shortcut to define classes with a *big* list of parameter. On class with such big list of parameters, we don't want to do pattern matching on all parameters (it will be completely unreadable), but prefer to define sensible extractors on them, if needed;
2 - real case class, with the hard pattern matching part.

"1" was not really sensible before default and named parameter, but now, it seems to be quite appropriate to match data structures protocol and all other types of simple data containers.

Well, it's just a statement of fact, I don't know what to do with that, but it seems that there is something.

[1] not exactly new, as it is one of the most used example when someone wants to show to a Javaiste how much more concise Scala is. More a kind of refined use case for what is provided today by case classes.

I'll take that as a thumbs-up to go ahead and try this as a plugin then, hopefully with the goal of getting something back into the compiler proper.I don't imagine it would be especially difficult, as I can just reuse all the heavy-lifting that's already in place for case classes and other instances of Product :)
(actually.. my current thinking is to name the annotation @Product)

It crosses over quite nicely with some of the autoproxy and reflection-esque stuff that I'm doing anyway, so even if the plugin never gets used and some totally different solution is found instead it still isn't wasted time - lots of fringe benefits to be had...

On 18 October 2010 13:53, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:

On Mon, Oct 18, 2010 at 12:46 PM, Kevin Wright <kev [dot] lee [dot] wright [at] gmail [dot] com> wrote:

Therein lies the rub... This pattern didn't really exist before named/default parameters came along with 2.8, so we're exploring a whole new design space here.
I'm seriously tempted to knock up a compiler-plugin that can generate the copy method and mix-in the product trait, driven by the presence of an annotation on the class.  Given that it wouldn't need any type information from outside of the unit, this can all be done before the namer phase - so none of the usual issues with method synthesis should arise.

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.

Cheers

  -- Martin

 

On 18 October 2010 11:12, Francois <fanf42 [at] gmail [dot] com> wrote:

On 18/10/2010 10:36, Jan Kotek wrote:

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

Intersting, so what we are seing here is a new[1] use case of case classes, where "case classes" are not used for the case part, but as immutable data structure with automatic equals, hashchode and copy method.

It's interesting, because it clearly splits the use cases for case class, and (I believe) with two level of difficulty on the compiler:
1 - immutable data structures : simple at the compiler level, it's just synthetising some methods. They are solelly a shortcut to define classes with a *big* list of parameter. On class with such big list of parameters, we don't want to do pattern matching on all parameters (it will be completely unreadable), but prefer to define sensible extractors on them, if needed;
2 - real case class, with the hard pattern matching part.

"1" was not really sensible before default and named parameter, but now, it seems to be quite appropriate to match data structures protocol and all other types of simple data containers.

Well, it's just a statement of fact, I don't know what to do with that, but it seems that there is something.

[1] not exactly new, as it is one of the most used example when someone wants to show to a Javaiste how much more concise Scala is. More a kind of refined use case for what is provided today by case classes.

On Mon, Oct 18, 2010 at 7:53 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:

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.

I see this more as case classes having too many compelling features that aren't easily available in another form. It would be nice if many of the case class features could be implemented through traits instead, and then keep case classes for their core purpose. Is there any reason toString, hashCode/equals, copy, etc, couldn't be delivered as a individual traits?

Mark Harrah has played around in this space before:

http://github.com/harrah/scala-starrless/compare/master...no_case_copy
http://github.com/harrah/scala-starrless/compare/master...casehlist

-jason

On Mon, Oct 18, 2010 at 3:22 PM, Nils Kilden-Pedersen wrote:
> On Mon, Oct 18, 2010 at 7:53 AM, martin odersky
> wrote:
>>
>> 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.
>
> I see this more as case classes having too many compelling features that
> aren't easily available in another form. It would be nice if many of the
> case class features could be implemented through traits instead, and then
> keep case classes for their core purpose.
> Is there any reason toString, hashCode/equals, copy, etc, couldn't be
> delivered as a individual traits?

If we pulled a lot of case class logic (equals, hashcode, toString, ...) into a dedicated trait self-typed as Product, then it would certainly make it easier to reuse this functionality elsewhere.  The copy method obviously couldn't be handled this way and I haven't given enough thought to isolating case-class extractor behaviour.
Still, it's a start...

I'd also like for Product to expose member names, but that puts us squarely back into the "improved reflection" discussion.  I guess it's technically possible now if you're willing to use Java reflection and methods from scalap; but I've already tried that, and it's a minefield right now!

On 18 October 2010 14:26, Jason Zaugg <jzaugg [at] gmail [dot] com> wrote:

Mark Harrah has played around in this space before:

http://github.com/harrah/scala-starrless/compare/master...no_case_copy
http://github.com/harrah/scala-starrless/compare/master...casehlist

-jason

On Mon, Oct 18, 2010 at 3:22 PM, Nils Kilden-Pedersen <nilskp [at] gmail [dot] com> wrote:
> On Mon, Oct 18, 2010 at 7:53 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch>
> wrote:
>>
>> 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.
>
> I see this more as case classes having too many compelling features that
> aren't easily available in another form. It would be nice if many of the
> case class features could be implemented through traits instead, and then
> keep case classes for their core purpose.
> Is there any reason toString, hashCode/equals, copy, etc, couldn't be
> delivered as a individual traits?

--
Kevin Wright

mail / gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com
pulse / skype: kev.lee.wright
twitter: @thecoda

Thanks for the plug! I took the opportunity to write about the second one:

http://apocalisp.wordpress.com/2010/10/18/type-level-programming-in-scal...

-Mark

Quoting Jason Zaugg :

> Mark Harrah has played around in this space before:
>
> http://github.com/harrah/scala-starrless/compare/master...no_case_copy
> http://github.com/harrah/scala-starrless/compare/master...casehlist
>
> -jason
>
> On Mon, Oct 18, 2010 at 3:22 PM, Nils Kilden-Pedersen
> wrote:
>> On Mon, Oct 18, 2010 at 7:53 AM, martin odersky
>> wrote:
>>>
>>> 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.
>>
>> I see this more as case classes having too many compelling features that
>> aren't easily available in another form. It would be nice if many of the
>> case class features could be implemented through traits instead, and then
>> keep case classes for their core purpose.
>> Is there any reason toString, hashCode/equals, copy, etc, couldn't be
>> delivered as a individual traits?
>
>