toDebugString as a Groovy core concept

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
MG
Reply | Threaded
Open this post in threaded view
|

toDebugString as a Groovy core concept

MG
Hi all,

I have created a jira for my proposed toDebugString Groovy feature:
https://issues.apache.org/jira/browse/GROOVY-8431

Cheers,
mg



Reply | Threaded
Open this post in threaded view
|

Re: toDebugString as a Groovy core concept

Guillaume Laforge
Administrator
Out of curiosity, you know about the dump() method on Object?
How close / different is it from your proposal of toDebugString()?
(dump() had that same purpose initially)

Guillaume


On Wed, Jan 3, 2018 at 6:39 PM, MG <[hidden email]> wrote:
Hi all,

I have created a jira for my proposed toDebugString Groovy feature:
https://issues.apache.org/jira/browse/GROOVY-8431

Cheers,
mg






--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Reply | Threaded
Open this post in threaded view
|

Re: toDebugString as a Groovy core concept

Ahm Avoby
Hi Guillaume,

thanks for that question.

I always felt GDK Object#dump() was meant to be used "as is", not to be overridden (overriding not mentioned in the Object doc, although there is of course nothing prohibiting one technically to do so). I also think that the name (while concise) is easy to misinterpret, while not being easy to discover through Intellisense.

The idea behind toDebugString is that it is easy to discover, overriding it to generate a string that represents the object in an easy to grasp, concise format is encouraged (the concept gets stronger, the more human-implemented toDebugString you have), and that the default implementation is only a stopgap fallback.

In addition, toDebugString is intended to become more powerful with the variety that takes additional parameters, detailing e.g. indentation.

I feel if toDebugString is something Groovy devs routinely implement, it could become a powerful debugging feature, in log output, but also in debuggers, giving a better human readable representation than is currently available.

Also in certain scenarios it could potentially make sense for GString to call toDebugString instead of toString on embedded objects in its own toString method.

Cheers,
mg


Guillaume Laforge <[hidden email]> schrieb am Mi., 3. Jän. 2018, 22:42:
Out of curiosity, you know about the dump() method on Object?
How close / different is it from your proposal of toDebugString()?
(dump() had that same purpose initially)

Guillaume


On Wed, Jan 3, 2018 at 6:39 PM, MG <[hidden email]> wrote:
Hi all,

I have created a jira for my proposed toDebugString Groovy feature:
https://issues.apache.org/jira/browse/GROOVY-8431

Cheers,
mg






--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

MG
Reply | Threaded
Open this post in threaded view
|

Re: toDebugString as a Groovy core concept

MG
In reply to this post by Guillaume Laforge
PS: I sent my reply from my son's gmail dev account, sorry for any  potentialy confusion :-)

-------- Ursprüngliche Nachricht --------
Von: Guillaume Laforge <[hidden email]>
Datum: 03.01.18 22:41 (GMT+01:00)
Betreff: Re: toDebugString as a Groovy core concept

Out of curiosity, you know about the dump() method on Object?
How close / different is it from your proposal of toDebugString()?
(dump() had that same purpose initially)

Guillaume


On Wed, Jan 3, 2018 at 6:39 PM, MG <[hidden email]> wrote:
Hi all,

I have created a jira for my proposed toDebugString Groovy feature:
https://issues.apache.org/jira/browse/GROOVY-8431

Cheers,
mg






--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform