[
https://issues.apache.org/jira/browse/GROOVY-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16326623#comment-16326623
]
mgroovy edited comment on GROOVY-8431 at 1/15/18 11:25 PM:
-----------------------------------------------------------
* @[~leonard84]: I totally agree that this would be the one way to go and
extend the conecpt. I just wanted to keep things simple and get the discussion
starting when I created the Jira ticket.
* I also did not have time to think about whether to use StringWriter or
StringBuilder would be the better choice (I use the simple version in my
project right now).
* One problem with the more flexible approach I see is, that the whole concept
is only worth something if people actually implement toDebugString - and
implementing the version taking a string building object takes just a little
bit more effort. With the indentation variety, people have the option to ignore
the parameters (at the cost of worse output quality, when complex objects are
output).
was (Author: emge):
* @[~leonard84]: I totally agree that this would be the one way to go and
extend the conecpt. I just wanted to keep things simple and get the discussion
starting when I created the Jira ticket.
* I also did not have time to think about whether to use StringWriter or
StringBuilder would be the better choice (I use the simple version in my
project right now)
* One problem with the more flexible approach I see is, that the whole concept
is only worth something if people actually implement toDebugString - and
implementing the version taking a string building object takes just a little
bit more effort. With the indentation variety, people have the option to ignore
the parameters (at the cost of worse output quality, when complex objects are
output).
> toDebugString method as a core concept
> --------------------------------------
>
> Key: GROOVY-8431
> URL: https://issues.apache.org/jira/browse/GROOVY-8431
> Project: Groovy
> Issue Type: Proposal
> Components: GEP, groovy-jdk
> Affects Versions: 3.x, 2.5.x
> Reporter: mgroovy
> Priority: Major
> Labels: features
>
> * Groovy should introduce a toDebugString method as a core concept, to
> separate debug to-string-conversion semantics from heavily oversubscribed
> standard Java Object#toString.
> * The power of this feature as a core concept lies in support to create
> ## Easy to use, human readable debug output of any object
> ## Creating debug output of objects owned by other objects (i.e. hierarchical
> debug output)
> * Adding this feature should be relatively simple, the challenge is to decide
> what features/parameters toDebugString should have, because this will be hard
> to change once the feature has been introduced.
> * The default implementation could
> ## Call the Java default Object#toString method
> ## Automatically create a reflection based output (performance will probably
> be bad for this, so it might be better to enable this behavior through an
> annotation)
> ## Returns something along the line of getClass().simpleName + '@' +
> System.identityHashcode(this) (though Object#toString is probably more useful)
> ## Fall back to the class' toString method (although in most cases it's most
> likely not what the user wants/expects)
> * An extension would be for an overloaded toDebugString to take an
> indentationLevel and indentationString parameter:
> {code}String toDebugString(int indentationLevel, String indentationString =
> '\t'){code}
> ** Implementations would be expected to indent the resulting String
> accordingly, which is very helpful for
> ### Complex objects which require a multi-line output to make sense of them
> in a debug log
> ### Outputting inner objects (e.g. a collection) owned by an object
> ** Groovy default implementation could be, to indent the result of calling
> toDebugString(), by scanning for newline sequences in the returned string
> * Questions:
> ## Is there a better name than the (relatively long) "toDebugString" ?
> *** toDebugString was suggested, since it is easy to discover, and its
> purpose should immediately clear
> ## Should the return type of toDebugString be GString instead of String ?
> *** This would allow for Groovy to process the objects embedded in the
> GString differently
> *** Having an additional GString toDebugGString() method might be an
> alternative
> ## Should there be additional parameters such as a terseness/verboseness
> parameter, which indicates how compact or verbose the generated debug string
> should be (implementations would be free to ignore this, of course) ?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
