This repository was archived by the owner on May 19, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 3
jrubyStorm task should use the jrubyStorm configuration by default #21
Comments
rtyler
pushed a commit
to rtyler/jruby-gradle-plugin
that referenced
this issue
Sep 10, 2015
…sing easier When using a member variable that is named the same as a property, the behavior from subclassing can be very confusing Take the following example: class Parent { protected String configuration = "foo" String getConfiguration() { return configuration } void doSomething() { logger.info("Parent using ${configuration}") } } class Child { String getConfiguration() { return 'hello' } void doSomething() { logger.info("Child using ${configuration}") super.doSomething() } } Invoking childInstance.doSomething() will output: Child using hello Parent using foo This can be remedied (pointed out by @ysb33r) by calling `this.@configuration` which will force a property lookup in Groovy. I personally find it less error-prone to keep member names ddifferent from the proprty names which expose them as a non-protected/private API. Fixes jruby-gradle/jruby-gradle-storm-plugin#21
rtyler
pushed a commit
to rtyler/jruby-gradle-plugin
that referenced
this issue
Sep 10, 2015
…sing easier When using a member variable that is named the same as a property, the behavior from subclassing can be very confusing Take the following example: class Parent { protected String configuration = "foo" String getConfiguration() { return configuration } void doSomething() { logger.info("Parent using ${configuration}") } } class Child { String getConfiguration() { return 'hello' } void doSomething() { logger.info("Child using ${configuration}") super.doSomething() } } Invoking childInstance.doSomething() will output: Child using hello Parent using foo This can be remedied (pointed out by @ysb33r) by calling `this.@configuration` which will force a property lookup in Groovy. I personally find it less error-prone to keep member names ddifferent from the proprty names which expose them as a non-protected/private API. Fixes jruby-gradle/jruby-gradle-storm-plugin#21
rtyler
pushed a commit
to rtyler/jruby-gradle-plugin
that referenced
this issue
Sep 10, 2015
…sing easier When using a member variable that is named the same as a property, the behavior from subclassing can be very confusing Take the following example: class Parent { protected String configuration = "foo" String getConfiguration() { return configuration } void doSomething() { logger.info("Parent using ${configuration}") } } class Child { String getConfiguration() { return 'hello' } void doSomething() { logger.info("Child using ${configuration}") super.doSomething() } } Invoking childInstance.doSomething() will output: Child using hello Parent using foo This can be remedied (pointed out by @ysb33r) by calling `this.@configuration` which will force a property lookup in Groovy. I personally find it less error-prone to keep member names ddifferent from the proprty names which expose them as a non-protected/private API. Fixes jruby-gradle/jruby-gradle-storm-plugin#21
rtyler
pushed a commit
to rtyler/jruby-gradle-plugin
that referenced
this issue
Sep 10, 2015
…sing easier When using a member variable that is named the same as a property, the behavior from subclassing can be very confusing Take the following example: class Parent { protected String configuration = "foo" String getConfiguration() { return configuration } void doSomething() { logger.info("Parent using ${configuration}") } } class Child { String getConfiguration() { return 'hello' } void doSomething() { logger.info("Child using ${configuration}") super.doSomething() } } Invoking childInstance.doSomething() will output: Child using hello Parent using foo This can be remedied (pointed out by @ysb33r) by calling `this.@configuration` which will force a property lookup in Groovy. I personally find it less error-prone to keep member names ddifferent from the proprty names which expose them as a non-protected/private API. Fixes jruby-gradle/jruby-gradle-storm-plugin#21
Turns out this is due to some weird interaction between redundantly named member variables and properties in Groovy and will be addressable with jruby-gradle/jruby-gradle-plugin#215 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
It's currently using jrubyJar, blech
The text was updated successfully, but these errors were encountered: