Fw: New question: Why can I set a task property without using = ?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Fw: New question: Why can I set a task property without using = ?

Luke Daley-2
I’ve just remembered that we don’t document the fact that we generate the methods that the guy is asking about below, and more largely we don’t have any documentation about class decoration. This is a problem.

Many of our examples use this style and we have no explanation anywhere of why this works and where it can be used. If it were an option I’d say let’s remove this feature (I know I was a big fan at its inception), but it’s now firmly entrenched. So, we should document it somehow. Question of course is what kind of priority this has relative to other work.

As an aside, this is the kind of “magic” I think we should aim to avoid in the future. It’s not the necessarily the class decoration or feature that’s the problem, but that for all intents and purposes this is “magic” as users have no practical way of understanding this besides poreing through obscure source code. This hurts our “approachability”. This is no revelation I know.

On 14 August 2014 at 6:39:02 am, Gradle ([hidden email]) wrote:

Gradle
User_default_medium
Today I realized that I used the following in my build:

war {
archiveName 'ROOT.war'
}

and that it worked fine, although the [War task documentation](http://www.gradle.org/docs/current/ds...) doesn't list any *method* named `archiveName`. The task has a *property* named `archiveName`, and I'm thus surprised I don't have to use the following syntax to set the archive name:

war {
archiveName = 'ROOT.war'
}

So, to help me in my quest to better understand groovy and gradle, could someone tell me

- if setting a property without using `=` is a groovy thing, or if it's a gradle thing
- if this is documented somewhere (I searched hard, but didn't find anything)
- if it's a good practice or not
- if this syntax is usable for any property of any object, or if it's limited to some types of objects/properties
- how and where it is implemented (if it's a gradle thing)

Thank you.
This message sent from the Gradle community on Get Satisfaction.
To unsubscribe or change your email settings, click here. Don't reply directly to this email.
Create a customer community for your company at GetSatisfaction.com.

Reply | Threaded
Open this post in threaded view
|

Re: Fw: New question: Why can I set a task property without using = ?

Lóránt Pintér
As a user, I agree on both points: it’s magic which would be best avoided in the future, but this particular piece of magic is pretty much entrenched. Most of our builds use this notation, and our developers expect the same notation from our internal plugins as well. For every new hire it seems weird, but they quickly get used to it, and then they are baffled when somewhere they need to use the = sign.

Which brings me to the question: would it be possible to use the same decorations with custom plugins, so we’d only need to declare a setter, and get the method form for free?

-- 
Lóránt

On Thursday 14 August 2014 at 00:25, Luke Daley wrote:

I’ve just remembered that we don’t document the fact that we generate the methods that the guy is asking about below, and more largely we don’t have any documentation about class decoration. This is a problem.

Many of our examples use this style and we have no explanation anywhere of why this works and where it can be used. If it were an option I’d say let’s remove this feature (I know I was a big fan at its inception), but it’s now firmly entrenched. So, we should document it somehow. Question of course is what kind of priority this has relative to other work.

As an aside, this is the kind of “magic” I think we should aim to avoid in the future. It’s not the necessarily the class decoration or feature that’s the problem, but that for all intents and purposes this is “magic” as users have no practical way of understanding this besides poreing through obscure source code. This hurts our “approachability”. This is no revelation I know.

On 14 August 2014 at 6:39:02 am, Gradle ([hidden email]) wrote:

Gradle
User_default_medium
Today I realized that I used the following in my build:

war {
archiveName 'ROOT.war'
}

and that it worked fine, although the [War task documentation](http://www.gradle.org/docs/current/ds...) doesn't list any *method* named `archiveName`. The task has a *property* named `archiveName`, and I'm thus surprised I don't have to use the following syntax to set the archive name:

war {
archiveName = 'ROOT.war'
}

So, to help me in my quest to better understand groovy and gradle, could someone tell me

- if setting a property without using `=` is a groovy thing, or if it's a gradle thing
- if this is documented somewhere (I searched hard, but didn't find anything)
- if it's a good practice or not
- if this syntax is usable for any property of any object, or if it's limited to some types of objects/properties
- how and where it is implemented (if it's a gradle thing)

Thank you.
This message sent from the Gradle community on Get Satisfaction.
To unsubscribe or change your email settings, click here. Don't reply directly to this email.
Create a customer community for your company at GetSatisfaction.com.


Reply | Threaded
Open this post in threaded view
|

RE: Fw: New question: Why can I set a task property without using = ?

KARR, DAVID

It may be in common use, but that doesn’t mean you have to recommend it.  It’s good to document it, as some people will expect it, but don’t emphasize its use.

 

I really like the concepts of Groovy, but this is the kind of “expressiveness” that’s always bothered me about it.  It’s expressive if you understand what it’s expressing. Reducing syntax is one thing, but removing it entirely just goes too far.

 

From: Lóránt Pintér [mailto:[hidden email]]
Sent: Wednesday, August 13, 2014 3:34 PM
To: [hidden email]
Subject: Re: [gradle-dev] Fw: New question: Why can I set a task property without using = ?

 

As a user, I agree on both points: it’s magic which would be best avoided in the future, but this particular piece of magic is pretty much entrenched. Most of our builds use this notation, and our developers expect the same notation from our internal plugins as well. For every new hire it seems weird, but they quickly get used to it, and then they are baffled when somewhere they need to use the = sign.

 

Which brings me to the question: would it be possible to use the same decorations with custom plugins, so we’d only need to declare a setter, and get the method form for free?

 

-- 

Lóránt

 

On Thursday 14 August 2014 at 00:25, Luke Daley wrote:

I’ve just remembered that we don’t document the fact that we generate the methods that the guy is asking about below, and more largely we don’t have any documentation about class decoration. This is a problem.

 

Many of our examples use this style and we have no explanation anywhere of why this works and where it can be used. If it were an option I’d say let’s remove this feature (I know I was a big fan at its inception), but it’s now firmly entrenched. So, we should document it somehow. Question of course is what kind of priority this has relative to other work.

 

As an aside, this is the kind of “magic” I think we should aim to avoid in the future. It’s not the necessarily the class decoration or feature that’s the problem, but that for all intents and purposes this is “magic” as users have no practical way of understanding this besides poreing through obscure source code. This hurts our “approachability”. This is no revelation I know.

On 14 August 2014 at 6:39:02 am, Gradle ([hidden email]) wrote:

Gradle

User_default_medium

Today I realized that I used the following in my build:

war {
archiveName 'ROOT.war'
}

and that it worked fine, although the [War task documentation](http://www.gradle.org/docs/current/ds...) doesn't list any *method* named `archiveName`. The task has a *property* named `archiveName`, and I'm thus surprised I don't have to use the following syntax to set the archive name:

war {
archiveName = 'ROOT.war'
}

So, to help me in my quest to better understand groovy and gradle, could someone tell me

- if setting a property without using `=` is a groovy thing, or if it's a gradle thing
- if this is documented somewhere (I searched hard, but didn't find anything)
- if it's a good practice or not
- if this syntax is usable for any property of any object, or if it's limited to some types of objects/properties
- how and where it is implemented (if it's a gradle thing)

Thank you.

This message sent from the Gradle community on Get Satisfaction.
To unsubscribe or change your email settings, click here. Don't reply directly to this email.

Create a customer community for your company at GetSatisfaction.com.