Skip to content
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

Closed
rtyler opened this issue Aug 20, 2015 · 1 comment
Closed
Assignees
Labels
Milestone

Comments

@rtyler
Copy link
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 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
@rtyler
Copy link
Member Author

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

No branches or pull requests

1 participant