groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ahm Avoby <>
Subject Re: toDebugString as a Groovy core concept
Date Wed, 03 Jan 2018 22:48:35 GMT
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

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.


Guillaume Laforge <> 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 <> wrote:
>> Hi all,
>> I have created a jira for my proposed toDebugString Groovy feature:
>> Cheers,
>> mg
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
> Blog:
> Social: @glaforge <> / Google+
> <>

View raw message