groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Re: G-String embedded Closure calling bug?
Date Sun, 31 Dec 2017 15:47:22 GMT
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 
> <nathanwharvey@gmail.com <mailto:nathanwharvey@gmail.com>> 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>


Mime
View raw message