This page is no longer maintained — Please continue to the home page at www.scala-lang.org

suggestion for case class toString method

13 replies
Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.

Case classes automatically generate a toString method:

scala> case class MyCaseClass (x: Int=1, y: Double=2.3, z:
Boolean=false)
defined class MyCaseClass

scala> val a = MyCaseClass()
a: MyCaseClass = MyCaseClass(1,2.3,false)

I think this would be a bit more useful if it showed the names of the
values:

a: MyCaseClass = MyCaseClass(x=1,y=2.3,z=false)

And why not add some whitespace?:

a: MyCaseClass = MyCaseClass(x=1, y=2.3, z=false)

As the number of values gets larger, this becomes more useful. Why
should I have to have to count fields to figure out what is what?

--Russ P.

Kris Nuttycombe
Joined: 2009-01-16,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for case class toString method
+1

On Thu, Sep 15, 2011 at 4:15 PM, Russ P. <russ [dot] paielli [at] gmail [dot] com> wrote:
Case classes automatically generate a toString method:

scala> case class MyCaseClass (x: Int=1, y: Double=2.3, z:
Boolean=false)
defined class MyCaseClass

scala> val a = MyCaseClass()
a: MyCaseClass = MyCaseClass(1,2.3,false)

I think this would be a bit more useful if it showed the names of the
values:

a: MyCaseClass = MyCaseClass(x=1,y=2.3,z=false)

And why not add some whitespace?:

a: MyCaseClass = MyCaseClass(x=1, y=2.3, z=false)

As the number of values gets larger, this becomes more useful. Why
should I have to have to count fields to figure out what is what?

--Russ P.

d_m
Joined: 2010-11-11,
User offline. Last seen 35 weeks 2 days ago.
Re: suggestion for case class toString method

On Thu, Sep 15, 2011 at 03:15:53PM -0700, Russ P. wrote:
> a: MyCaseClass = MyCaseClass(x=1, y=2.3, z=false)

Great suggestion. I agree.

dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: suggestion for case class toString method

On Thu, Sep 15, 2011 at 19:15, Russ P. wrote:
> Case classes automatically generate a toString method:
>
> scala> case class MyCaseClass (x: Int=1, y: Double=2.3, z:
> Boolean=false)
> defined class MyCaseClass
>
> scala> val a = MyCaseClass()
> a: MyCaseClass = MyCaseClass(1,2.3,false)
>
> I think this would be a bit more useful if it showed the names of the
> values:
>
> a: MyCaseClass = MyCaseClass(x=1,y=2.3,z=false)
>
> And why not add some whitespace?:
>
> a: MyCaseClass = MyCaseClass(x=1, y=2.3, z=false)
>
> As the number of values gets larger, this becomes more useful. Why
> should I have to have to count fields to figure out what is what?

This might break some code, though toString should really be
restricted to debugging. Some might use it as serialization, though.

Nevertheless, I, for one, am all for it.

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for case class toString method

On 09/16/2011 09:13 AM, Daniel Sobral wrote:
> On Thu, Sep 15, 2011 at 19:15, Russ P. wrote:
>> Case classes automatically generate a toString method:
>>
>> scala> case class MyCaseClass (x: Int=1, y: Double=2.3, z:
>> Boolean=false)
>> defined class MyCaseClass
>>
>> scala> val a = MyCaseClass()
>> a: MyCaseClass = MyCaseClass(1,2.3,false)
>>
>> I think this would be a bit more useful if it showed the names of the
>> values:
>>
>> a: MyCaseClass = MyCaseClass(x=1,y=2.3,z=false)
>>
>> And why not add some whitespace?:
>>
>> a: MyCaseClass = MyCaseClass(x=1, y=2.3, z=false)
>>
>> As the number of values gets larger, this becomes more useful. Why
>> should I have to have to count fields to figure out what is what?
> This might break some code, though toString should really be
> restricted to debugging. Some might use it as serialization, though.
>
> Nevertheless, I, for one, am all for it.
>
I believe this has come up before. FWIW, Haskell does this.

If such a (incompatible?) change were to be made, I'd also go for the
introduction of a lens instead (or perhaps as well as) of .copy and
getter methods for each record field. The scalaz users have discussed
this quite a lot, clarified all the useful bits and one clever guy even
produced a plugin.

I'm happy to discuss the advantage of this, since I don't believe I did
last time I brought it up, so perhaps that is why it was not so compelling.

Seth Tisue
Joined: 2008-12-16,
User offline. Last seen 34 weeks 3 days ago.
Re: suggestion for case class toString method

I want this. I don't care if it breaks every Scala program in the
world. It's the right thing.

Seth Tisue
Joined: 2008-12-16,
User offline. Last seen 34 weeks 3 days ago.
Re: suggestion for case class toString method

It's https://issues.scala-lang.org/browse/SI-3967 by the way.
Discussion in comments.

--
Seth Tisue | Northwestern University | http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: suggestion for case class toString method
Well, I see that Paul Phillips is not too crazy about the idea. I have no idea how hard it would be to implement, but it would sure make case classes more convenient for non-trivial data records. And it is consistent with passing arguments by name rather than by order.

--Russ P.


On Thu, Sep 15, 2011 at 6:59 PM, Seth Tisue <seth [at] tisue [dot] net> wrote:
It's https://issues.scala-lang.org/browse/SI-3967 by the way.
Discussion in comments.

--
Seth Tisue | Northwestern University | http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/



--
http://RussP.us
Alex Cruise
Joined: 2008-12-17,
User offline. Last seen 2 years 26 weeks ago.
Re: suggestion for case class toString method
On Thu, Sep 15, 2011 at 7:16 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
Well, I see that Paul Phillips is not too crazy about the idea. I have no idea how hard it would be to implement, but it would sure make case classes more convenient for non-trivial data records. And it is consistent with passing arguments by name rather than by order.

"While we're on the subject," if we're talking about making big changes to Product#toString (and having it name the arguments by default would be a big +1 from me), let's kick the generality up a notch and discuss the feasibility of generating Show/Read[1] instances for case classes.  The compiler, or one of his plugins, is really the man for the job, since he can tell you definitively whether all types reachable from the constructor argument type(s) also have Show/Read instances.
-0xe1a
1: http://www.haskell.org/tutorial/stdclasses.html#sect8.3
odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: suggestion for case class toString method

On Fri, Sep 16, 2011 at 7:05 PM, Alex Cruise wrote:
> On Thu, Sep 15, 2011 at 7:16 PM, Russ Paielli
> wrote:
>>
>> Well, I see that Paul Phillips is not too crazy about the idea. I have no
>> idea how hard it would be to implement, but it would sure make case classes
>> more convenient for non-trivial data records. And it is consistent with
>> passing arguments by name rather than by order.
>
> "While we're on the subject," if we're talking about making big changes to
> Product#toString (and having it name the arguments by default would be a big
> +1 from me), let's kick the generality up a notch and discuss the
> feasibility of generating Show/Read[1] instances for case classes.  The
> compiler, or one of his plugins, is really the man for the job, since he can
> tell you definitively whether all types reachable from the constructor
> argument type(s) also have Show/Read instances.
> -0xe1a
> 1: http://www.haskell.org/tutorial/stdclasses.html#sect8.3

Show/Read instances for case classes, and, more generally "scrap your
boilerplate" techniques would be very interesting to investigate. And
if it's a big improvement, we will work hard to find ways to migrate
that into the language.

An isolated change like changing the ways classes print will almost
certainly not be accepted. It would break a lot of programs and tests,
and for very little apparent gain. Generally, we are way beyond the
stage where we can break programs just because we fancy a change might
be nice.

Cheers

dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: suggestion for case class toString method

On Sun, Sep 18, 2011 at 12:08, martin odersky wrote:
> On Fri, Sep 16, 2011 at 7:05 PM, Alex Cruise wrote:
>> On Thu, Sep 15, 2011 at 7:16 PM, Russ Paielli
>> wrote:
>>>
>>> Well, I see that Paul Phillips is not too crazy about the idea. I have no
>>> idea how hard it would be to implement, but it would sure make case classes
>>> more convenient for non-trivial data records. And it is consistent with
>>> passing arguments by name rather than by order.
>>
>> "While we're on the subject," if we're talking about making big changes to
>> Product#toString (and having it name the arguments by default would be a big
>> +1 from me), let's kick the generality up a notch and discuss the
>> feasibility of generating Show/Read[1] instances for case classes.  The
>> compiler, or one of his plugins, is really the man for the job, since he can
>> tell you definitively whether all types reachable from the constructor
>> argument type(s) also have Show/Read instances.
>> -0xe1a
>> 1: http://www.haskell.org/tutorial/stdclasses.html#sect8.3
>
> Show/Read instances for case classes, and, more generally "scrap your
> boilerplate" techniques would be very interesting to investigate. And
> if it's a big improvement, we will work hard to find ways to migrate
> that into the language.
>
> An isolated change like changing the ways classes print will almost
> certainly not be accepted. It would break a lot of programs and tests,
> and for very little apparent gain. Generally, we are way beyond the
> stage where we can break programs just because we fancy a change might
> be nice.

One thing that drew my attention while reading on Nemerle macros at
http://nemerle.org/macros.html was the way they implemented C-style
for loops. Well, the serializable example was pretty cool as well, but
what called my attention is that, were a similar facility available in
Scala, for-comprehensions could have been a macro.

Naturally, as a Scala programmer, the way they use pattern matching
against the expressions passed as parameters was also of much
interest.

dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: suggestion for case class toString method

Oops, sorry, I thought I was in an entirely different thread.

On Sun, Sep 18, 2011 at 22:04, Daniel Sobral wrote:
> On Sun, Sep 18, 2011 at 12:08, martin odersky wrote:
>> On Fri, Sep 16, 2011 at 7:05 PM, Alex Cruise wrote:
>>> On Thu, Sep 15, 2011 at 7:16 PM, Russ Paielli
>>> wrote:
>>>>
>>>> Well, I see that Paul Phillips is not too crazy about the idea. I have no
>>>> idea how hard it would be to implement, but it would sure make case classes
>>>> more convenient for non-trivial data records. And it is consistent with
>>>> passing arguments by name rather than by order.
>>>
>>> "While we're on the subject," if we're talking about making big changes to
>>> Product#toString (and having it name the arguments by default would be a big
>>> +1 from me), let's kick the generality up a notch and discuss the
>>> feasibility of generating Show/Read[1] instances for case classes.  The
>>> compiler, or one of his plugins, is really the man for the job, since he can
>>> tell you definitively whether all types reachable from the constructor
>>> argument type(s) also have Show/Read instances.
>>> -0xe1a
>>> 1: http://www.haskell.org/tutorial/stdclasses.html#sect8.3
>>
>> Show/Read instances for case classes, and, more generally "scrap your
>> boilerplate" techniques would be very interesting to investigate. And
>> if it's a big improvement, we will work hard to find ways to migrate
>> that into the language.
>>
>> An isolated change like changing the ways classes print will almost
>> certainly not be accepted. It would break a lot of programs and tests,
>> and for very little apparent gain. Generally, we are way beyond the
>> stage where we can break programs just because we fancy a change might
>> be nice.
>
> One thing that drew my attention while reading on Nemerle macros at
> http://nemerle.org/macros.html was the way they implemented C-style
> for loops. Well, the serializable example was pretty cool as well, but
> what called my attention is that, were a similar facility available in
> Scala, for-comprehensions could have been a macro.
>
> Naturally, as a Scala programmer, the way they use pattern matching
> against the expressions passed as parameters was also of much
> interest.
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

ichoran
Joined: 2009-08-14,
User offline. Last seen 2 years 3 weeks ago.
Re: suggestion for case class toString method
I'm all for an autogenerated method that uses parameter names in a String, but if you ever have a collection of case classes, repeating the variable names is a huge waste of space:

  List((1,2), (3,4))  // Now
  List((_1=1, _2=2), (_1=3, _2=4)) // To Be (or Not, hopefully)

If you're dealing with them one by one, presumably calling a method to get the long version is not too much to ask.  (Especially if it recursively calls the verbose method on members.)

  --Rex


On Thu, Sep 15, 2011 at 6:15 PM, Russ P. <russ [dot] paielli [at] gmail [dot] com> wrote:
Case classes automatically generate a toString method:

scala> case class MyCaseClass (x: Int=1, y: Double=2.3, z:
Boolean=false)
defined class MyCaseClass

scala> val a = MyCaseClass()
a: MyCaseClass = MyCaseClass(1,2.3,false)

I think this would be a bit more useful if it showed the names of the
values:

a: MyCaseClass = MyCaseClass(x=1,y=2.3,z=false)

And why not add some whitespace?:

a: MyCaseClass = MyCaseClass(x=1, y=2.3, z=false)

As the number of values gets larger, this becomes more useful. Why
should I have to have to count fields to figure out what is what?

--Russ P.

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: suggestion for case class toString method

Yeah, even if it is not the default behavior of toString, it seems to
me that there should be some method available to automatically print
out a case class with the field names shown. Otherwise you force
everyone who wants that behavior to "roll their own."

--Russ P.

On Sep 18, 10:56 pm, Rex Kerr wrote:
> I'm all for an autogenerated method that uses parameter names in a String,
> but if you ever have a collection of case classes, repeating the variable
> names is a huge waste of space:
>
>   List((1,2), (3,4))  // Now
>   List((_1=1, _2=2), (_1=3, _2=4)) // To Be (or Not, hopefully)
>
> If you're dealing with them one by one, presumably calling a method to get
> the long version is not too much to ask.  (Especially if it recursively
> calls the verbose method on members.)
>
>   --Rex
>
> On Thu, Sep 15, 2011 at 6:15 PM, Russ P. wrote:
> > Case classes automatically generate a toString method:
>
> > scala> case class MyCaseClass (x: Int=1, y: Double=2.3, z:
> > Boolean=false)
> > defined class MyCaseClass
>
> > scala> val a = MyCaseClass()
> > a: MyCaseClass = MyCaseClass(1,2.3,false)
>
> > I think this would be a bit more useful if it showed the names of the
> > values:
>
> > a: MyCaseClass = MyCaseClass(x=1,y=2.3,z=false)
>
> > And why not add some whitespace?:
>
> > a: MyCaseClass = MyCaseClass(x=1, y=2.3, z=false)
>
> > As the number of values gets larger, this becomes more useful. Why
> > should I have to have to count fields to figure out what is what?
>
> > --Russ P.

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland