Skip to content
This repository has been archived by the owner. 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

jrubyStorm task should use the jrubyStorm configuration by default #21

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

Comments

@rtyler
Copy link
Member

@rtyler 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
…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
…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
…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
…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 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.
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.