[jira] [Comment Edited] (GROOVY-8431) toDebugString method as a core concept
[
https://issues.apache.org/jira/browse/GROOVY-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (GROOVY-8431) toDebugString method as a core concept
[
https://issues.apache.org/jira/browse/GROOVY-8431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16326595#comment-16326595
]
Leonard Brünings commented on GROOVY-8431:
--
While not supporting this feature, I'd suggest to use a {{ToStringHelper}}
similar to guava instead of some parameters like
String toDebugString(int indentationLevel, String indentationString = '\t')
this way we can be flexible, while having a standard api/way to output
structured content. The {{DebugStringBuilder}} would be an interface with a
default implementation, a developer/tool could choose to supply a different
implementation for their needs. The GroovyObject would add a default
{{toDebugString()}} method that in turn calls the overridable
{{toDebugString(DebugStringBuilder builder)}}
> 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)
[jira] [Updated] (GROOVY-8450) Make `grape install` set non-zero exit status on failure
[
https://issues.apache.org/jira/browse/GROOVY-8450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Allan Lewis updated GROOVY-8450:
Affects Version/s: 2.4.13
> Make `grape install` set non-zero exit status on failure
>
>
> Key: GROOVY-8450
> URL: https://issues.apache.org/jira/browse/GROOVY-8450
> Project: Groovy
> Issue Type: Improvement
> Components: Grape
>Affects Versions: 2.5.0-beta-2, 2.4.13
>Reporter: Allan Lewis
>Priority: Minor
>
> When {{grape install}} can't find a module, it reports an error as follows:
> {noformat}
> $ grape install foo bar
> ...
> :: problems summary ::
> WARNINGS
> module not found: foo#bar;latest.default
> ...{noformat}
> However, it nevertheless exits with status 0: surely it would be better to
> exit non-zero in this scenario?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8450) Make `grape install` set non-zero exit status on failure
Allan Lewis created GROOVY-8450:
---
Summary: Make `grape install` set non-zero exit status on failure
Key: GROOVY-8450
URL: https://issues.apache.org/jira/browse/GROOVY-8450
Project: Groovy
Issue Type: Improvement
Components: Grape
Affects Versions: 2.6.0-alpha-2, 2.4.13, 2.5.0-beta-2, 3.0.0-alpha-1
Reporter: Allan Lewis
When {{grape install}} can't find a module, it reports an error as follows:
{noformat}
$ grape install foo bar
...
:: problems summary ::
WARNINGS
module not found: foo#bar;latest.default
...{noformat}
However, it nevertheless exits with status 0: surely it would be better to exit
non-zero in this scenario?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8450) Make `grape install` set non-zero exit status on failure
[
https://issues.apache.org/jira/browse/GROOVY-8450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Allan Lewis updated GROOVY-8450:
Affects Version/s: (was: 2.6.0-alpha-2)
(was: 2.4.13)
(was: 3.0.0-alpha-1)
> Make `grape install` set non-zero exit status on failure
>
>
> Key: GROOVY-8450
> URL: https://issues.apache.org/jira/browse/GROOVY-8450
> Project: Groovy
> Issue Type: Improvement
> Components: Grape
>Affects Versions: 2.5.0-beta-2, 2.4.13
>Reporter: Allan Lewis
>Priority: Minor
>
> When {{grape install}} can't find a module, it reports an error as follows:
> {noformat}
> $ grape install foo bar
> ...
> :: problems summary ::
> WARNINGS
> module not found: foo#bar;latest.default
> ...{noformat}
> However, it nevertheless exits with status 0: surely it would be better to
> exit non-zero in this scenario?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8338) Calling Stream.of from groovy class in JDK 9 fails
[
https://issues.apache.org/jira/browse/GROOVY-8338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16326317#comment-16326317
]
Daniel Sun commented on GROOVY-8338:
I found javac creates `Integer` array for `Stream.of(1, 2, 3)`, but groovy
creates `Object` array. Maybe it is the cause why `Stream.of` fails in Java9,
which is more strict to verify.
> Calling Stream.of from groovy class in JDK 9 fails
> --
>
> Key: GROOVY-8338
> URL: https://issues.apache.org/jira/browse/GROOVY-8338
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.12
>Reporter: Marcus Nylander
>Priority: Major
>
> Trying to call Stream.of from groovy class (groovy version 2.4.12) using JDK
> 9 (jdk 9 181) fails.
> Example:
> {code}
> package test
> import java.util.stream.Stream
> class B {
> static void main(String[] args) {
> Stream.of("1").forEach({ println(it) })
> }
> }
> {code}
> The code above fails with:
> Exception in thread "main" java.lang.IncompatibleClassChangeError: Method
> java.util.stream.Stream.of(Ljava/lang/Object;)Ljava/util/stream/Stream; must
> be InterfaceMethodref constant
> at java_util_stream_Stream$of.call(Unknown Source)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
> at test.B.main(B.groovy:7)
> The same occurs for other interface static methods also:
> {code}
> public interface D {
> static D of(String s) {
> return new D() {
> };
> }
> }
> class C {
> static void main(String[] args) {
> D.of("1")
> }
> }
> {code}
> Also fails with:
> Exception in thread "main" java.lang.IncompatibleClassChangeError: Method
> test.D.of(Ljava/lang/String;)Ltest/D; must be InterfaceMethodref constant
> at test.D$of.call(Unknown Source)
> at
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
> at test.C.main(C.groovy:7)
> Running with JDK 8 works fine.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8449) Inconsistency in accessing uppercase properties in @CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniil Ovchinnikov updated GROOVY-8449:
---
Summary: Inconsistency in accessing uppercase properties in @CompileStatic
(was: Inconsistency in accessing properties in @CompileStatic)
> Inconsistency in accessing uppercase properties in @CompileStatic
> -
>
> Key: GROOVY-8449
> URL: https://issues.apache.org/jira/browse/GROOVY-8449
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.13
>Reporter: Daniil Ovchinnikov
>Priority: Major
>
> {code:title=bugs.groovy}
> class Fields {
> def Field = "field"
> def getField() { "getter" }
> }
> @CompileStatic
> def usageCompileStatic() {
> new Fields().Field
> }
> def usageCompileDynamic() {
> new Fields().Field
> }
> println usageCompileDynamic() // field
> println usageCompileStatic() // getter{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8449) Inconsistency in accessing properties in @CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16326262#comment-16326262
]
Daniil Ovchinnikov commented on GROOVY-8449:
Please confirm this is intended behaviour or clarify which of these cases
should be fixed.
> Inconsistency in accessing properties in @CompileStatic
> ---
>
> Key: GROOVY-8449
> URL: https://issues.apache.org/jira/browse/GROOVY-8449
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 2.4.13
>Reporter: Daniil Ovchinnikov
>Priority: Major
>
> {code:title=bugs.groovy}
> class Fields {
> def Field = "field"
> def getField() { "getter" }
> }
> @CompileStatic
> def usageCompileStatic() {
> new Fields().Field
> }
> def usageCompileDynamic() {
> new Fields().Field
> }
> println usageCompileDynamic() // field
> println usageCompileStatic() // getter{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8449) Inconsistency in accessing properties in @CompileStatic
Daniil Ovchinnikov created GROOVY-8449:
--
Summary: Inconsistency in accessing properties in @CompileStatic
Key: GROOVY-8449
URL: https://issues.apache.org/jira/browse/GROOVY-8449
Project: Groovy
Issue Type: Bug
Components: Static compilation
Affects Versions: 2.4.13
Reporter: Daniil Ovchinnikov
{code:title=bugs.groovy}
class Fields {
def Field = "field"
def getField() { "getter" }
}
@CompileStatic
def usageCompileStatic() {
new Fields().Field
}
def usageCompileDynamic() {
new Fields().Field
}
println usageCompileDynamic() // field
println usageCompileStatic() // getter{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8448) Local variable is accessible via explicit this
Daniil Ovchinnikov created GROOVY-8448:
--
Summary: Local variable is accessible via explicit this
Key: GROOVY-8448
URL: https://issues.apache.org/jira/browse/GROOVY-8448
Project: Groovy
Issue Type: Bug
Affects Versions: 2.4.13
Reporter: Daniil Ovchinnikov
{code:groovy}
def var = "local var"
new Runnable() {
def getVar() { "getter" }
void run() {
println var // as expected: local var
println this.var // expected: getter, actual: local var
}
}.run()
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
