Let's start with a problem statement. I'd like to see a solution that:

1. Solves the (huge) problem where someone tries to configure a pre-defined
property but accidentally introduces a new one. By "pre-defined" I mean a
property that's baked into the object model or added by a plugin via an
extension or convention object.
2. Allows dynamic properties to stay simple, intuitive, and ad-hoc
3. Discourages plugins from using dynamic properties
4. Doesn't try to solve other problems in this space (I'm not really aware
of any)

The proposed plan is very well thought out, but I wonder whether we need
such features as multiple namespaces (violates 3., 4. in my list) and
mandatory registration via an "add" method (violates 2.). Here is my
proposal:

Dynamic properties are accessible via a special property on an enhanced
object, say 'ext'. In my mind, 'ext' is just a map:

project.ext.foo = "some value"
println project.ext.foo

A dynamic property is introduced by setting a value (possibly `null`) like
shown above. After a dynamic property has been introduced (and only then),
it can also be accessed from the top level:

project.foo = "new value"
println project.foo

(Whether we actually want to support access from the top level is an
independent question.)

That's it. My proposal solves 1. because a dynamic property first has to be
introduced via the 'ext' property.(*) It solves 2. because it's all about
setting and getting properties, with no other API involved. It solves 3.
because it provides no API for registering properties, property meta-data,
and namespaces, thereby not encouraging plugins to make use of dynamic
properties. (**)

Cheers,
Peter

(*) We could improve this further by checking for and handling (e.g
disallowing) name clashes between pre-configured and dynamic properties.

(**) I feel that plugins should use class-based extensions/conventions,
which have advantages in terms of documentation, testing, and tooling.







--
View this message in context: 
http://gradle.1045684.n5.nabble.com/dynamic-properties-proposed-plan-tp5487655p5490571.html
Sent from the gradle-dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to