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 <glafo...@gmail.com> 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 <mg...@arscreat.com> 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 > > Blog: http://glaforge.appspot.com/ > Social: @glaforge <http://twitter.com/glaforge> / Google+ > <https://plus.google.com/u/0/114130972232398734985/posts> >
