But are users confused by GString today? Or would they be confused if its behaviour changed and their code stopped working? Also, which users do you have in mind, noobies, experts, DSL writers, ...?
I for one would like GString to stay the way it is. The examples you presented don't show problems with GString, rather they show how other issues can manifest through GString. The first example is a toString method with side effects, which is definitely poor practice. If you wanted to showcase in general the interaction of mutable objects with GString, then the current behavior (GString reflects the object's state) might actually be what users want. I.e. GString as a crude but effective template solution. The second example is a problem with type inference. Accessing a Map<String, ?> by a key which is not a String should raise a warning. Also if it's not already the case the static compiler could handle String x = "$k" by silently inserting a toString() call, i.e., emitting an implicit type conversion. On Sun, 9 Sep 2018 at 07:10, Daniel.Sun <sun...@apache.org> wrote: > Hi MG, > > The original target of the proposal is to make GString not confuse > users and make GString behave same both in dynamic and static compilation > mode. so it will only introduces breaking changes just in some edge cases. > > Cheers, > Daniel.Sun > > > > ----- > Daniel Sun > Apache Groovy committer > Blog: http://blog.sunlan.me > Twitter: @daniel_sun > > -- > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >
