Re: Groovy Wrapper for Bintray API

2016-02-29 Thread Gerald Wiltse
Thank you sir! Actually... would I be able to just use the plugin library? Are methods exposed in similar ways? Gerald R. Wiltse jerrywil...@gmail.com On Mon, Feb 29, 2016 at 6:26 PM, Schalk Cronjé wrote: > You can re-use some code from here - > https://github.com/ysb33r/bintray/blob/master/

Re: Groovy Wrapper for Bintray API

2016-02-29 Thread Schalk Cronjé
You can re-use some code from here - https://github.com/ysb33r/bintray/blob/master/gradle-plugin/src/main/groovy/org/ysb33r/gradle/bintray/BintrayAPI.groovy On 29/02/2016 23:13, Gerald Wiltse wrote: I don't suppose anyone has created a groovy wrapper "library" for bintray have they? Just hopi

Groovy Wrapper for Bintray API

2016-02-29 Thread Gerald Wiltse
I don't suppose anyone has created a groovy wrapper "library" for bintray have they? Just hoping to get lucky. As I set out to write my third such a wrapper for a popular REST API in 2 months, i keep thinking "haven't 100 people already done this work?". I checked, and Bintray hasn't done the sw

RE: Optional parentheses for methods with all uppercase names

2016-02-29 Thread Winnebeck, Jason
I didn't see this explanation in the linked thread, but from what I've heard in situations where a symbol can be interpreted as a function or a Class, the rule that is used to choose between the cases is the initial uppercase letter. So "Foo" is the name of a class but "foo" is the name of a loc

Re: Confirming getProperties() works differently (inside vs outside)

2016-02-29 Thread Gerald Wiltse
Ok, so it's a symptom of calling withTraits dynamically, now it makes sense. That's much less common of a use case than standard trait implementation. While I would think a "groovy reflection" feature to capture these types of properties would make a lot of sense, I can see this being very difficu

Re: Confirming getProperties() works differently (inside vs outside)

2016-02-29 Thread Dinko Srkoč
On 29 February 2016 at 13:48, Gerald Wiltse wrote: > This looks like an elegant solution. Are you confirming that there's no way > for a method inside "class Chameleon" to achieve the goal? Just by moving > method out to a trait, it becomes aware of all the inherited and implemented > props? No

Re: Confirming getProperties() works differently (inside vs outside)

2016-02-29 Thread Jochen Theodorou
On 29.02.2016 03:23, Gerald Wiltse wrote: Is there a way for the Chameleon class to ever see that it has a "lastColor" property? class Chameleon{ String color = "green" void printAllMyProperties(){ this.properties.each{println it} } } trait ColorChanging { Stri

Re: Confirming getProperties() works differently (inside vs outside)

2016-02-29 Thread Gerald Wiltse
This looks like an elegant solution. Are you confirming that there's no way for a method inside "class Chameleon" to achieve the goal? Just by moving method out to a trait, it becomes aware of all the inherited and implemented props? Not bad... THANKS! this list has been really awesome for lea

Re: Confirming getProperties() works differently (inside vs outside)

2016-02-29 Thread Dinko Srkoč
I know this is not exactly what you asked, but would something like this work for you? class Chameleon{ String color = "green" } trait ColorChanging { String lastColor def changeColor = {newcolor -> lastColor = this.color this.color = newcolor