This repository was archived by the owner on May 19, 2019. It is now read-only.
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: