does a

Property

convention mutate the original property, or does it return a new one? I'm definitely writing code like it returns a new one...

It works like a

set()

with lower priority (won't change the property value if one has already been

set()

)

so, in theory though it mutates. I guess I worded that poorly...

The javadoc is absolutely clear: https://docs.gradle.org/current/javadoc/org/gradle/api/provider/Property.html#convention(org.gradle.api.provider.Provider)

Returns: this

I mean to say that the Property object is mutated, not the value

If it would return a new instance, it would largely work against the principle for which `Property`s were introduced.

right, but what I've seen is I set up the empty

Property

and then call convention... so the property is kind of set up first. I'm not doing something like

Property.convention("...")

to create them, gradle is injecting or whatever. since I'm always chaining then I've basically set them up right before extracting, so from an API perspective... I wasn't really able to intuit whether and what kind of builder. (I mean

prop.convention("foo").get()

doesn't intuit that convention is mutating, and we aren't really supposed to be calling get most of the time. I should have read the docs though...

Usually you wouldn't set convention right before getting the value, for that you can simply do

getOrElse

. As I said, usually you set the convention in the plugin that registers the according task or extension, so that every consumer sees that convention if no explicit value was set.

when you're doing it in the plugin right before you access it...

Usually when I register the task or extension. And nowhere in the plugin I get a property value, because that only brings the same problems

afterEvaluate

brings, ordering problems and race conditions.

so you don't use convention plugins? build-logic/buildSrc? that's cool

Why should I not use convention plugins? And no, it is no problem at all to write plugins that don't directly use those values.

then why have the values if nothing ever uses them?

As I explained previously,

Property

is for evaluation at execution time. Whenever you evaluate at configuration time, you create ordering problems and race conditions just like if you would use

afterEvaluate

. `Property`s are for wiring together and only evaluated at execution time. If I need something at configuration time, I don't make it a

Property

, but a function parameter, or nested one level so that the setting is wrapped in a function call.

oh, I think I know what you're talking about... you're obsessing over the

.get()

which I also could have used

.map

but since I'm working on configuring publishing I'm working with a bunch of stuff which isn't lazy

Yeah, well, that's just a usual builder / call chain pattern.

right, but it's also a functional pattern

Yep, you can never differentiate those two from is usage

most builders have some kind of

build()

anyways, I get how it works now

Yeah, its not exactly builder, just saying there your also get this returned. It is call chain pattern as mentioned :-)

and not even all builders are mutable, so anyways, that's my point of confusion. It mostly looks like functional code

And I object to that "most", I know many builder pattern applications where the class is not named ...Builder and the method not named build. 🤷‍♂️

you can object, most only requires 50.1% 😉

So? ;-)

and I'm only talking java land to be fair, maybe only java

Me too mostly

because I have no idea what scala/groovy/etc are up to

No

assertj for example

It's pointless anyway. Even builder pattern, call chain pattern, fluent API, all not necessarily require that the same instance is returned, just that the type is the same, but could as well be a new instance

I've never heard of "call chain pattern"

Call it fluent API if you prefer :-)

guess I should have said interface? but meh, the api is fluent. fowler is always right 😛 https://martinfowler.com/bliki/FluentInterface.html