On 16/02/2012, at 7: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:
The line on dynamic properties would be that no shared plugins should ever use them. The original use case for arbitrary storage buckets was for lightweight extension for “user code”, that is things local to the build. Whether this happens or not, use of dynamic properties for anything more than very specific build/organisation local features would be strongly discouraged. That's not in question. I'm ok with completely deferring multiple namespaces for the time being. This would just mean that we would have to support one pre existing bucket for a while, which I think is a reasonable assumption. > 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 The only contention with the original proposal here is that you aren't required to explicitly register properties. I think I can live with this. It would be a shame to get this wrong and then have to deprecate it later, but not the end of the world. > (Whether we actually want to support access from the top level is an > independent question.) Right, which we are deferring entirely. > 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, I don't see this is a valid argument. It provides no strictly static API, but there is still an API. I'm not keen on exposing something that implements Map. Then we have to deal with removal and other issues. Supporting groovy property notation is a given, but I don't want project.ext instanceof Map. If you need the properties as a map you can do project.ext.properties as per the standard groovy idiom. > and namespaces, thereby not encouraging plugins to make use of dynamic > properties. (**) I think we can defer this question for the time being. > 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. This isn't really in question. The question is whether or not we give users a way to categorise their dynamic properties without resorting to extension classes. The only issue that we need to solve soon is what the API is for registering properties, because I'll need to move tests to this syntax to avoid deprecation warnings in our tests. Everything else is not time critical for me. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
