New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jrubyStorm task should use the jrubyStorm configuration by default #21

Closed
rtyler opened this Issue Aug 20, 2015 · 1 comment

Comments

1 participant
@rtyler
Member

rtyler commented Aug 20, 2015

It's currently using jrubyJar, blech

@rtyler rtyler added the bug label Aug 20, 2015

@rtyler rtyler modified the milestone: 0.4.0 Aug 31, 2015

rtyler added a commit to rtyler/jruby-gradle-plugin that referenced this issue Sep 10, 2015

Avoid member vs. property name collisions in JRubyJar to make subclas…
…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 added a commit to rtyler/jruby-gradle-plugin that referenced this issue Sep 10, 2015

Avoid member vs. property name collisions in JRubyJar to make subclas…
…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 added a commit to rtyler/jruby-gradle-plugin that referenced this issue Sep 10, 2015

Avoid member vs. property name collisions in JRubyJar to make subclas…
…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 added a commit to rtyler/jruby-gradle-plugin that referenced this issue Sep 10, 2015

Avoid member vs. property name collisions in JRubyJar to make subclas…
…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

This comment has been minimized.

Show comment
Hide comment
@rtyler

rtyler Sep 10, 2015

Member

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

Member

rtyler commented Sep 10, 2015

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 join this conversation on GitHub. Already have an account? Sign in to comment