this is basically what I presented earlier this week... however I do also think there is value in understanding the accessibility of the top level object... since this is what was originally intended...
so... project.ext.foo = "value" - defines a new property foo and assigns it's value project.foo - invokes the propertyMissing... which checks the map "ext".. uses if it is there.. fails otherwise (you are not allow to dynamically add a property this way, however reassignment or accessibility is fine) Ken Sipe | [email protected] | blog: http://kensipe.blogspot.com On Feb 16, 2012, at 1:59 PM, Peter Niederwieser wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
