I know where you are coming from. On the other hand, this is maybe the
sole reason why anyone would need a language after Groovy: Historic
features being frozen because of the fear that a change might break some
existing code...
However I do not think that this behavior, as unexpected as it might be,
falls into that category, given that my code makes heavy use of
embedding expressions in GString|s and I have never run into it. The
only place where this might be a problem, is, if you actually want to
debug output some information about a Closure object, and you instead
get an (unexpected) Closure evaluation.
I would therefore suggest another solution for this: In my code I have a
ToDebugString interface, which requires a class implements a
String toDebugString()
method, which is expected to return human readable debug information
about the object.
I think would be a generally useful concept, by allowing the programmer
to distinguish between debug- and other toString-semantics if need be.
I propose Groovy introduces toDebugString as a core concept, with
default implementation calling the Java default Object#toString method.
(Or returns something along the line of getClass().simpleName + '@' +
System.identityHashcode(this); falling back to the class' toString
method would also be an option, although in most cases it's most likely
not what the user wants/expects.)
As an extension (and the way I use it), toDebugString could look like this:
String toDebugString(int indentationLevel = 0, String indentationString
= '\t')
and implementations are 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.
What do you guys think ?
mg
On 31.12.2017 11:58, Guillaume Laforge wrote:
We've settled on that behavior a long time ago, so it's quite blurry
in my mind, to be honest.
I'd be a bit afraid of making changes to how things are working now,
as it might have some unintended consequences.
I mean, making some changes there could break people's code in
unexpected places, and I think it would be pretty hard to track and find.
With age (not that I'm old, but I've been involved in Groovy for 14
years now), I become a bit more conservative, and afraid of making
anything that could be breaking people's code :-(
Guillaume
On Sun, Dec 31, 2017 at 4:57 AM, Nathan Harvey
<[email protected] <mailto:[email protected]>> wrote:
Are there any more thoughts on whether or not this behavior should be
changed? I say it is confusing and unnecessary. I think it's
important to
keep the behavior advertised for Closures intact, eg: "hello {->
0}" should
still render 0, but a reference to a Closure should not
automatically call
toString()
--
Sent from:
http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
<http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html>
--
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>
