Those tuples are out to get me

A case class with 140 members?I would advise refactoring...

On 28 January 2010 13:29, John Ky <newhoggy@gmail.com> wrote:

Help!

I'm running into the dreaded tuple size space limitation.

value Tuple50 is not a member of package scala
value Tuple50 is not a member of package scala
value Tuple40 is not a member of package scala
value Tuple23 is not a member of package scala
value Tuple30 is not a member of package scala
value Tuple58 is not a member of package scala
value Tuple140 is not a member of package scala
value Tuple34 is not a member of package scala
value Tuple23 is not a member of package scala
value Tuple27 is not a member of package scala
value Tuple51 is not a member of package scala

And all I'm doing is defining case classes.  Is there anything I can do to avoid this error?

Thanks,

-John

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

Tuple 140?!  That means that you're asking for a class with 140 different constructor parameters, doesn't it?  Yikes!

Can't you do one or more of
  - Use lists/arrays instead
  - Group your classes so they're less monolithic
  - Set in the constructor only those parameters you really want to match on, and have other methods to set the rest

I can't imagine pattern matching a 140-element case class is going to be much fun to write.  That's three full lines of "_,_,_,_,_,_".  And what if you count wrong and are off by one in the placement of a parameter you care about?

You _can_ use nested expressions in case statements, you know.  There's no reason to have everything on the same level.

  --Rex

On Thu, Jan 28, 2010 at 8:29 AM, John Ky <newhoggy@gmail.com> wrote:

Help!

I'm running into the dreaded tuple size space limitation.

value Tuple50 is not a member of package scala
value Tuple50 is not a member of package scala
value Tuple40 is not a member of package scala
value Tuple23 is not a member of package scala
value Tuple30 is not a member of package scala
value Tuple58 is not a member of package scala
value Tuple140 is not a member of package scala
value Tuple34 is not a member of package scala
value Tuple23 is not a member of package scala
value Tuple27 is not a member of package scala
value Tuple51 is not a member of package scala

And all I'm doing is defining case classes.  Is there anything I can do to avoid this error?

Thanks,

-John

On Thu, Jan 28, 2010 at 08:43:47AM -0500, Rex Kerr wrote:
> I can't imagine pattern matching a 140-element case class is going to
> be much fun to write. That's three full lines of "_,_,_,_,_,_". And
> what if you count wrong and are off by one in the placement of a
> parameter you care about?

I would wildly but probably correctly guess this is generated code.

I agree, you can easily do the same via this:

case class X(val a1: Tuple20[..], val a2: Tuple20[..], val a3:
Tuple20[..], val a4: Tuple20[..], val a5: Tuple20[..], val a6:
Tuple20[..], val a7: Tuple20[..])

:)
Dimitris

2010/1/28 Kevin Wright :
> A case class with 140 members?
> I would advise refactoring...
>
> On 28 January 2010 13:29, John Ky wrote:
>>
>> Help!
>>
>> I'm running into the dreaded tuple size space limitation.
>>
>> value Tuple50 is not a member of package scala
>> value Tuple50 is not a member of package scala
>> value Tuple40 is not a member of package scala
>> value Tuple23 is not a member of package scala
>> value Tuple30 is not a member of package scala
>> value Tuple58 is not a member of package scala
>> value Tuple140 is not a member of package scala
>> value Tuple34 is not a member of package scala
>> value Tuple23 is not a member of package scala
>> value Tuple27 is not a member of package scala
>> value Tuple51 is not a member of package scala
>>
>> And all I'm doing is defining case classes.  Is there anything I can do to
>> avoid this error?
>>
>> Thanks,
>>
>> -John
>>
>
>
>
> --
> Kevin Wright
>
> mail/google talk: kev.lee.wright@googlemail.com
> wave: kev.lee.wright@googlewave.com
> skype: kev.lee.wright
> twitter: @thecoda
>
>

The last time this came up as an issue, it was parsing JSONThe solution then was that the json was poorly structured...

On 28 January 2010 13:51, Paul Phillips <paulp@improving.org> wrote:

On Thu, Jan 28, 2010 at 08:43:47AM -0500, Rex Kerr wrote:
> I can't imagine pattern matching a 140-element case class is going to
> be much fun to write.  That's three full lines of "_,_,_,_,_,_".  And
> what if you count wrong and are off by one in the placement of a
> parameter you care about?

I would wildly but probably correctly guess this is generated code.

--
Paul Phillips      | We act as though comfort and luxury were the chief
In Theory          | requirements of life, when all that we need to make us
Empiricist         | really happy is something to be enthusiastic about.
i'll ship a pulp   |     -- Charles Kingsley

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

What are you doing? Is this some form of code generator?

-Stefan

2010/1/28 John Ky <newhoggy@gmail.com>

Help!

I'm running into the dreaded tuple size space limitation.

value Tuple50 is not a member of package scala
value Tuple50 is not a member of package scala
value Tuple40 is not a member of package scala
value Tuple23 is not a member of package scala
value Tuple30 is not a member of package scala
value Tuple58 is not a member of package scala
value Tuple140 is not a member of package scala
value Tuple34 is not a member of package scala
value Tuple23 is not a member of package scala
value Tuple27 is not a member of package scala
value Tuple51 is not a member of package scala

And all I'm doing is defining case classes.  Is there anything I can do to avoid this error?

Thanks,

-John

On Thu, 28 Jan 2010 08:43:47 -0500, Rex Kerr wrote:
> Tuple 140?! That means that you're asking for a class with 140 different
> constructor parameters, doesn't it? Yikes!
>
> Can't you do one or more of
> - Use lists/arrays instead
> - Group your classes so they're less monolithic
> - Set in the constructor only those parameters you really want to match
> on, and have other methods to set the rest
Or
- Set in the first constructor parameter list only those parameters you
really want to match on, and put the rest in a second parameter list:
case class Foo(p1:..., ..., p22:...)(val p23:..., ..., val p140:...)

On Thu, Jan 28, 2010 at 8:51 AM, Paul Phillips <paulp@improving.org> wrote:

On Thu, Jan 28, 2010 at 08:43:47AM -0500, Rex Kerr wrote:
> I can't imagine pattern matching a 140-element case class is going to
> be much fun to write.

I would wildly but probably correctly guess this is generated code.

I agree, but if you don't expose this to the outside world _at all_, then you can do everything with List[Any] or ArrayBuffer[Any] and let the code-generator rather than the compiler keep the types straight.  If you do expose it, then someone might have to write a 140-parameter case class match by hand.

  --Rex

On Thursday January 28 2010, Dimitris Andreou wrote:
> I agree, you can easily do the same via this:
>
> case class X(val a1: Tuple20[..], val a2: Tuple20[..], val a3:
> Tuple20[..], val a4: Tuple20[..], val a5: Tuple20[..], val a6:
> Tuple20[..], val a7: Tuple20[..])
>
> :)
>
> Dimitris

Are you the person with whom I was discussing this on #scala the other
day?

There is nothing good about doing this just so you can use case classes.

Randall Schulz

2010/1/28 Randall R Schulz :
> On Thursday January 28 2010, Dimitris Andreou wrote:
>> I agree, you can easily do the same via this:
>>
>> case class X(val a1: Tuple20[..], val a2: Tuple20[..], val a3:
>> Tuple20[..], val a4: Tuple20[..], val a5: Tuple20[..], val a6:
>> Tuple20[..], val a7: Tuple20[..])
>>
>> :)
>>
>> Dimitris
>
> Are you the person with whom I was discussing this on #scala the other
> day?

No, last time we talked there was many moons ago.

>
> There is nothing good about doing this just so you can use case classes.

Why? This is the perfect way to model 140-dimensional spaces. Seriously!!

Dimitris

>
>
> Randall Schulz
>

On 28 January 2010 17:09, Dimitris Andreou <jim.andreou@gmail.com> wrote:

2010/1/28 Randall R Schulz <rschulz@sonic.net>:
> On Thursday January 28 2010, Dimitris Andreou wrote:
>> I agree, you can easily do the same via this:
>>
>> case class X(val a1: Tuple20[..], val a2: Tuple20[..], val a3:
>> Tuple20[..], val a4: Tuple20[..], val a5: Tuple20[..], val a6:
>> Tuple20[..], val a7: Tuple20[..])
>>
>> :)
>>
>> Dimitris
>
> Are you the person with whom I was discussing this on #scala the other
> day?

No, last time we talked there was many moons ago.

>
> There is nothing good about doing this just so you can use case classes.

Why? This is the perfect way to model 140-dimensional spaces. Seriously!!

Name one such space where each and every dimension has to be explicitly named!
I seriously can't see any benefit in a case class of this size as opposed to, say, an array(which would also perform somewhat better)
There's absolutely no chance of you convincing me that it's somehow practical to pattern-match against this monstrosity.

Dimitris

>
>
> Randall Schulz
>

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

I don't know about 140, but Earth has over 50 distinct periods. Sure, one can store that in an array, but one would have to store the correspondence between index and type of period _somewhere_.   So, do not dismiss this so readily. I do think, though, that there's no need to making it a _case_ class. Particularly with auto-generated code, which can just as easily generate all the methods provided by a case class.

On Thu, Jan 28, 2010 at 3:17 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

On 28 January 2010 17:09, Dimitris Andreou <jim.andreou@gmail.com> wrote:

2010/1/28 Randall R Schulz <rschulz@sonic.net>:
> On Thursday January 28 2010, Dimitris Andreou wrote:
>> I agree, you can easily do the same via this:
>>
>> case class X(val a1: Tuple20[..], val a2: Tuple20[..], val a3:
>> Tuple20[..], val a4: Tuple20[..], val a5: Tuple20[..], val a6:
>> Tuple20[..], val a7: Tuple20[..])
>>
>> :)
>>
>> Dimitris
>
> Are you the person with whom I was discussing this on #scala the other
> day?

No, last time we talked there was many moons ago.

>
> There is nothing good about doing this just so you can use case classes.

Why? This is the perfect way to model 140-dimensional spaces. Seriously!!

Name one such space where each and every dimension has to be explicitly named!
I seriously can't see any benefit in a case class of this size as opposed to, say, an array (which would also perform somewhat better)
There's absolutely no chance of you convincing me that it's somehow practical to pattern-match against this monstrosity.

Dimitris

>
>
> Randall Schulz
>

On Thu, Jan 28, 2010 at 3:24 PM, Daniel Sobral <dcsobral@gmail.com> wrote:

I don't know about 140, but Earth has over 50 distinct periods. Sure, one can store that in an array, but one would have to store the correspondence between index and type of period _somewhere_.

Maybe the method names aren't the best place to store that information?  Maybe instead:

case class Period(name: String, period: Double) { }
class Earth(val periods: Map[String,Period]) { ... }

  --Rex

A map is, essentially, a dynamic field. At the very least, one loses syntactic safety. But I'll just defer to relational algebra.   The point, however, is not that those 140 fields couldn't be stored in many other ways. The point is that there MIGHT be 140 actual, distinct, named fields. Just not in blog app. :-)
On Thu, Jan 28, 2010 at 6:55 PM, Rex Kerr <ichoran@gmail.com> wrote:

On Thu, Jan 28, 2010 at 3:24 PM, Daniel Sobral <dcsobral@gmail.com> wrote:

I don't know about 140, but Earth has over 50 distinct periods. Sure, one can store that in an array, but one would have to store the correspondence between index and type of period _somewhere_.

Maybe the method names aren't the best place to store that information?  Maybe instead:

case class Period(name: String, period: Double) { }
class Earth(val periods: Map[String,Period]) { ... }

  --Rex

--
Daniel C. Sobral

I travel to the future all the time.

Hi Stefan,

Yes, I'm compiling from another language into Scala.

Cheers,

-John

On Fri, Jan 29, 2010 at 12:44 AM, Stefan Langer <mailtolanger@googlemail.com> wrote:

What are you doing? Is this some form of code generator?

-Stefan

2010/1/28 John Ky <newhoggy@gmail.com>

Help!

I'm running into the dreaded tuple size space limitation.

value Tuple50 is not a member of package scala
value Tuple50 is not a member of package scala
value Tuple40 is not a member of package scala
value Tuple23 is not a member of package scala
value Tuple30 is not a member of package scala
value Tuple58 is not a member of package scala
value Tuple140 is not a member of package scala
value Tuple34 is not a member of package scala
value Tuple23 is not a member of package scala
value Tuple27 is not a member of package scala
value Tuple51 is not a member of package scala

And all I'm doing is defining case classes.  Is there anything I can do to avoid this error?

Thanks,

-John

Hi Rex,

Hi Rex,

Not really, because you can do other things with a case class than pattern match.  For example, I provide a default object which can be transformed via the copy method, and there are additional methods that I add that make this even easier.

Cheers,

-John

On Fri, Jan 29, 2010 at 1:06 AM, Rex Kerr <ichoran@gmail.com> wrote:

On Thu, Jan 28, 2010 at 8:51 AM, Paul Phillips <paulp@improving.org> wrote:

On Thu, Jan 28, 2010 at 08:43:47AM -0500, Rex Kerr wrote:
> I can't imagine pattern matching a 140-element case class is going to
> be much fun to write.

I would wildly but probably correctly guess this is generated code.

I agree, but if you don't expose this to the outside world _at all_, then you can do everything with List[Any] or ArrayBuffer[Any] and let the code-generator rather than the compiler keep the types straight.  If you do expose it, then someone might have to write a 140-parameter case class match by hand.

  --Rex

Trouble is, if what I'm doing is an established protocol, I can't just change definitions willy nilly.  Sure it was poor design on the part of the person who wrote structures with 140 members, but I'm stuck with it for the time being.

On Fri, Jan 29, 2010 at 12:55 AM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

The last time this came up as an issue, it was parsing JSONThe solution then was that the json was poorly structured...

On 28 January 2010 13:51, Paul Phillips <paulp@improving.org> wrote:

On Thu, Jan 28, 2010 at 08:43:47AM -0500, Rex Kerr wrote:
> I can't imagine pattern matching a 140-element case class is going to
> be much fun to write.  That's three full lines of "_,_,_,_,_,_".  And
> what if you count wrong and are off by one in the placement of a
> parameter you care about?

I would wildly but probably correctly guess this is generated code.

--
Paul Phillips      | We act as though comfort and luxury were the chief
In Theory          | requirements of life, when all that we need to make us
Empiricist         | really happy is something to be enthusiastic about.
i'll ship a pulp   |     -- Charles Kingsley

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

2010/1/28 Kevin Wright :
>
>
> On 28 January 2010 17:09, Dimitris Andreou wrote:
>>
>> 2010/1/28 Randall R Schulz :
>> > On Thursday January 28 2010, Dimitris Andreou wrote:
>> >> I agree, you can easily do the same via this:
>> >>
>> >> case class X(val a1: Tuple20[..], val a2: Tuple20[..], val a3:
>> >> Tuple20[..], val a4: Tuple20[..], val a5: Tuple20[..], val a6:
>> >> Tuple20[..], val a7: Tuple20[..])
>> >>
>> >> :)
>> >>
>> >> Dimitris
>> >
>> > Are you the person with whom I was discussing this on #scala the other
>> > day?
>>
>> No, last time we talked there was many moons ago.
>>
>> >
>> > There is nothing good about doing this just so you can use case classes.
>>
>> Why? This is the perfect way to model 140-dimensional spaces. Seriously!!
>
>
> Name one such space where each and every dimension has to be explicitly
> named!

Nobody said it is common :)
It's not the necessity of having distinct names though (names could be
just ints), its the distinct domains (otherwise, an n-dimensional cube
can easily be represented for example by an Array[T], as others have
mentioned).

Of course, there are many applications that do model hundreds of
dimensions, e.g. as columns in relational tables. Denormalizing them
could lead to a table with a very large number of columns. Also note
that a Tuple2 is enough to simulate every TupleN (each tuple
representing a dimension coordinate plus another tuple), just as all
relational databases could be theoretically designed using tables with
3 columns (i.e. 2 columns plus 1 for identity).

> I seriously can't see any benefit in a case class of this size as opposed
> to, say, an array
> (which would also perform somewhat better)
> There's absolutely no chance of you convincing me that it's somehow
> practical to pattern-match against this monstrosity.

By the way, 140 dimensions can be modelled by Tuple2 forming a binary
tree of height=8, so for example if you wanted to find a single
matching dimension, you would have to type "_" around 8 times, not
139.

(Last but not least, please note the tongue-in-cheekness in all of this :)

>
>
>> Dimitris
>>
>> >
>> >
>> > Randall Schulz
>> >
>
>
>
> --
> Kevin Wright
>
> mail/google talk: kev.lee.wright@googlemail.com
> wave: kev.lee.wright@googlewave.com
> skype: kev.lee.wright
> twitter: @thecoda
>
>

The copy method relies just on named and default parameters, as far as I know. You can generate them as well.

On Thu, Jan 28, 2010 at 8:09 PM, John Ky <newhoggy@gmail.com> wrote:

Hi Rex,

Hi Rex,

Not really, because you can do other things with a case class than pattern match.  For example, I provide a default object which can be transformed via the copy method, and there are additional methods that I add that make this even easier.

Cheers,

-John

On Fri, Jan 29, 2010 at 1:06 AM, Rex Kerr <ichoran@gmail.com> wrote:

On Thu, Jan 28, 2010 at 8:51 AM, Paul Phillips <paulp@improving.org> wrote:

On Thu, Jan 28, 2010 at 08:43:47AM -0500, Rex Kerr wrote:
> I can't imagine pattern matching a 140-element case class is going to
> be much fun to write.

I would wildly but probably correctly guess this is generated code.

I agree, but if you don't expose this to the outside world _at all_, then you can do everything with List[Any] or ArrayBuffer[Any] and let the code-generator rather than the compiler keep the types straight.  If you do expose it, then someone might have to write a 140-parameter case class match by hand.

  --Rex

--
Daniel C. Sobral

I travel to the future all the time.

In case anyone doesn't know, the parameter limit is just for case
classes, as they inherit from ProductN. If you are generating code,
perhaps you could use regular classes. Equals, toString, and hashCode
could also be generated, if required.

-jason

On Thu, Jan 28, 2010 at 11:32 PM, John Ky wrote:
> Trouble is, if what I'm doing is an established protocol, I can't just
> change definitions willy nilly.  Sure it was poor design on the part of the
> person who wrote structures with 140 members, but I'm stuck with it for the
> time being.

Problem here is that's an expensive copy, to the tune of 139 refs
If the data in question has a natural composition of, say, 3 groups of 40 values and 2 groups of 5 values, then the cost of cloning drops to 8 references being copied

when cloning immutable data structures and changing a single value, then performance really gains from the ability for each reference copied to point to the largest partitions possible.


On 28 January 2010 22:43, Daniel Sobral <dcsobral@gmail.com> wrote:

The copy method relies just on named and default parameters, as far as I know. You can generate them as well.

On Thu, Jan 28, 2010 at 8:09 PM, John Ky <newhoggy@gmail.com> wrote:

Hi Rex,

Hi Rex,

Not really, because you can do other things with a case class than pattern match.  For example, I provide a default object which can be transformed via the copy method, and there are additional methods that I add that make this even easier.

Cheers,

-John

On Fri, Jan 29, 2010 at 1:06 AM, Rex Kerr <ichoran@gmail.com> wrote:

On Thu, Jan 28, 2010 at 8:51 AM, Paul Phillips <paulp@improving.org> wrote:

On Thu, Jan 28, 2010 at 08:43:47AM -0500, Rex Kerr wrote:
> I can't imagine pattern matching a 140-element case class is going to
> be much fun to write.

I would wildly but probably correctly guess this is generated code.

I agree, but if you don't expose this to the outside world _at all_, then you can do everything with List[Any] or ArrayBuffer[Any] and let the code-generator rather than the compiler keep the types straight.  If you do expose it, then someone might have to write a 140-parameter case class match by hand.

  --Rex

--
Daniel C. Sobral

I travel to the future all the time.

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

No. When cloning [sic] immutable *eagerly-evaluated* data structures...

Scalaz did have/does have/will have (I forget) lazy product values (I
know it recently got a lazy stream that works) for performance
enhancements in compositional code.

Kevin Wright wrote:
> Problem here is that's an expensive copy, to the tune of 139 refs
>
> If the data in question has a natural composition of, say, 3 groups of 40
> values and 2 groups of 5 values, then the cost of cloning drops to 8
> references being copied
>
> when cloning immutable data structures and changing a single value, then
> performance really gains from the ability for each reference copied to point
> to the largest partitions possible.
>
>
>
> On 28 January 2010 22:43, Daniel Sobral wrote:
>
>
>> The copy method relies just on named and default parameters, as far as I
>> know. You can generate them as well.
>>
>>
>> On Thu, Jan 28, 2010 at 8:09 PM, John Ky wrote:
>>
>>
>>> Hi Rex,
>>>
>>> Hi Rex,
>>>
>>> Not really, because you can do other things with a case class than pattern
>>> match. For example, I provide a default object which can be transformed via
>>> the copy method, and there are additional methods that I add that make this
>>> even easier.
>>>
>>> Cheers,
>>>
>>> -John
>>>
>>>
>>> On Fri, Jan 29, 2010 at 1:06 AM, Rex Kerr wrote:
>>>
>>>
>>>> On Thu, Jan 28, 2010 at 8:51 AM, Paul Phillips wrote:
>>>>
>>>>
>>>>> On Thu, Jan 28, 2010 at 08:43:47AM -0500, Rex Kerr wrote:
>>>>>
>>>>>> I can't imagine pattern matching a 140-element case class is going to
>>>>>> be much fun to write.
>>>>>>
>>>>> I would wildly but probably correctly guess this is generated code.
>>>>>
>>>>>
>>>> I agree, but if you don't expose this to the outside world _at all_, then
>>>> you can do everything with List[Any] or ArrayBuffer[Any] and let the
>>>> code-generator rather than the compiler keep the types straight. If you do
>>>> expose it, then someone might have to write a 140-parameter case class match
>>>> by hand.
>>>>
>>>> --Rex
>>>>
>>>>
>>>>
>> --
>> Daniel C. Sobral
>>
>> I travel to the future all the time.
>>
>>
>
>
>
>

Right... If the copy references everything back to the original, except for the "modified" valueThe logic is sound, but is this how scala actually does it?

On 28 January 2010 23:12, Tony Morris <tonymorris@gmail.com> wrote:

No. When cloning [sic] immutable *eagerly-evaluated* data structures...

Scalaz did have/does have/will have (I forget) lazy product values (I
know it recently got a lazy stream that works) for performance
enhancements in compositional code.

Kevin Wright wrote:
> Problem here is that's an expensive copy, to the tune of 139 refs
>
> If the data in question has a natural composition of, say, 3 groups of 40
> values and 2 groups of 5 values, then the cost of cloning drops to 8
> references being copied
>
> when cloning immutable data structures and changing a single value, then
> performance really gains from the ability for each reference copied to point
> to the largest partitions possible.
>
>
>
> On 28 January 2010 22:43, Daniel Sobral <dcsobral@gmail.com> wrote:
>
>
>> The copy method relies just on named and default parameters, as far as I
>> know. You can generate them as well.
>>
>>
>> On Thu, Jan 28, 2010 at 8:09 PM, John Ky <newhoggy@gmail.com> wrote:
>>
>>
>>> Hi Rex,
>>>
>>> Hi Rex,
>>>
>>> Not really, because you can do other things with a case class than pattern
>>> match.  For example, I provide a default object which can be transformed via
>>> the copy method, and there are additional methods that I add that make this
>>> even easier.
>>>
>>> Cheers,
>>>
>>> -John
>>>
>>>
>>> On Fri, Jan 29, 2010 at 1:06 AM, Rex Kerr <ichoran@gmail.com> wrote:
>>>
>>>
>>>> On Thu, Jan 28, 2010 at 8:51 AM, Paul Phillips <paulp@improving.org>wrote:
>>>>
>>>>
>>>>>  On Thu, Jan 28, 2010 at 08:43:47AM -0500, Rex Kerr wrote:
>>>>>
>>>>>> I can't imagine pattern matching a 140-element case class is going to
>>>>>> be much fun to write.
>>>>>>
>>>>> I would wildly but probably correctly guess this is generated code.
>>>>>
>>>>>
>>>> I agree, but if you don't expose this to the outside world _at all_, then
>>>> you can do everything with List[Any] or ArrayBuffer[Any] and let the
>>>> code-generator rather than the compiler keep the types straight.  If you do
>>>> expose it, then someone might have to write a 140-parameter case class match
>>>> by hand.
>>>>
>>>>   --Rex
>>>>
>>>>
>>>>
>> --
>> Daniel C. Sobral
>>
>> I travel to the future all the time.
>>
>>
>
>
>
>



--
Tony Morris
http://tmorris.net/

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

Yes. Scala's tuples are eagerly-evaluated.

scala> (7, error("boo!"))._1
java.lang.RuntimeException: boo!

Kevin Wright wrote:
> Right... If the copy references everything back to the original, except for
> the "modified" value
> The logic is sound, but is this how scala actually does it?
>
> On 28 January 2010 23:12, Tony Morris wrote:
>
>
>> No. When cloning [sic] immutable *eagerly-evaluated* data structures...
>>
>> Scalaz did have/does have/will have (I forget) lazy product values (I
>> know it recently got a lazy stream that works) for performance
>> enhancements in compositional code.
>>
>> Kevin Wright wrote:
>>
>>> Problem here is that's an expensive copy, to the tune of 139 refs
>>>
>>> If the data in question has a natural composition of, say, 3 groups of 40
>>> values and 2 groups of 5 values, then the cost of cloning drops to 8
>>> references being copied
>>>
>>> when cloning immutable data structures and changing a single value, then
>>> performance really gains from the ability for each reference copied to
>>>
>> point
>>
>>> to the largest partitions possible.
>>>
>>>
>>>
>>> On 28 January 2010 22:43, Daniel Sobral wrote:
>>>
>>>
>>>
>>>> The copy method relies just on named and default parameters, as far as I
>>>> know. You can generate them as well.
>>>>
>>>>
>>>> On Thu, Jan 28, 2010 at 8:09 PM, John Ky wrote:
>>>>
>>>>
>>>>
>>>>> Hi Rex,
>>>>>
>>>>> Hi Rex,
>>>>>
>>>>> Not really, because you can do other things with a case class than
>>>>>
>> pattern
>>
>>>>> match. For example, I provide a default object which can be
>>>>>
>> transformed via
>>
>>>>> the copy method, and there are additional methods that I add that make
>>>>>
>> this
>>
>>>>> even easier.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> -John
>>>>>
>>>>>
>>>>> On Fri, Jan 29, 2010 at 1:06 AM, Rex Kerr wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Thu, Jan 28, 2010 at 8:51 AM, Paul Phillips >>>>>
>>> wrote:
>>>
>>>>>>
>>>>>>> On Thu, Jan 28, 2010 at 08:43:47AM -0500, Rex Kerr wrote:
>>>>>>>
>>>>>>>
>>>>>>>> I can't imagine pattern matching a 140-element case class is going
>>>>>>>>
>> to
>>
>>>>>>>> be much fun to write.
>>>>>>>>
>>>>>>>>
>>>>>>> I would wildly but probably correctly guess this is generated code.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> I agree, but if you don't expose this to the outside world _at all_,
>>>>>>
>> then
>>
>>>>>> you can do everything with List[Any] or ArrayBuffer[Any] and let the
>>>>>> code-generator rather than the compiler keep the types straight. If
>>>>>>
>> you do
>>
>>>>>> expose it, then someone might have to write a 140-parameter case class
>>>>>>
>> match
>>
>>>>>> by hand.
>>>>>>
>>>>>> --Rex
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> --
>>>> Daniel C. Sobral
>>>>
>>>> I travel to the future all the time.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
>>
>
>
>

Hi Kevin,

Not ideal, but at least the copy method can tranformed multiple fields in one copy.

Cheers,

-John

On Fri, Jan 29, 2010 at 10:09 AM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

Problem here is that's an expensive copy, to the tune of 139 refs
If the data in question has a natural composition of, say, 3 groups of 40 values and 2 groups of 5 values, then the cost of cloning drops to 8 references being copied

when cloning immutable data structures and changing a single value, then performance really gains from the ability for each reference copied to point to the largest partitions possible.


On 28 January 2010 22:43, Daniel Sobral <dcsobral@gmail.com> wrote:

The copy method relies just on named and default parameters, as far as I know. You can generate them as well.

On Thu, Jan 28, 2010 at 8:09 PM, John Ky <newhoggy@gmail.com> wrote:

Hi Rex,

Hi Rex,

Not really, because you can do other things with a case class than pattern match.  For example, I provide a default object which can be transformed via the copy method, and there are additional methods that I add that make this even easier.

Cheers,

-John

On Fri, Jan 29, 2010 at 1:06 AM, Rex Kerr <ichoran@gmail.com> wrote:

On Thu, Jan 28, 2010 at 8:51 AM, Paul Phillips <paulp@improving.org> wrote:

On Thu, Jan 28, 2010 at 08:43:47AM -0500, Rex Kerr wrote:
> I can't imagine pattern matching a 140-element case class is going to
> be much fun to write.

I would wildly but probably correctly guess this is generated code.

I agree, but if you don't expose this to the outside world _at all_, then you can do everything with List[Any] or ArrayBuffer[Any] and let the code-generator rather than the compiler keep the types straight.  If you do expose it, then someone might have to write a 140-parameter case class match by hand.

  --Rex

--
Daniel C. Sobral

I travel to the future all the time.

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

Hi Jason,

I got this approach to work.

Thanks,

-John

On Fri, Jan 29, 2010 at 9:40 AM, Jason Zaugg <jzaugg@gmail.com> wrote:

In case anyone doesn't know, the parameter limit is just for case
classes, as they inherit from ProductN. If you are generating code,
perhaps you could use regular classes. Equals, toString, and hashCode
could also be generated, if required.

-jason

On Thu, Jan 28, 2010 at 11:32 PM, John Ky <newhoggy@gmail.com> wrote:
> Trouble is, if what I'm doing is an established protocol, I can't just
> change definitions willy nilly.  Sure it was poor design on the part of the
> person who wrote structures with 140 members, but I'm stuck with it for the
> time being.