On 6/15/07, Matt Benson <[EMAIL PROTECTED]> wrote:
I am actively working on this as we speak, actually, and I'm pleased so far with my results.
FTR Matt, I still haven't read anything to convince me that write access via <property> is desirable, needed, and good. I'm not trying to put a damper on your efforts, but so far the use cases I've seen for "write" are better handled by custom tasks. What about the <*ant> tasks? These "things" which are not string properties, how do they percolate to sub-Projects? We have clear semantic for properties and references passing, so it would be much clearer and "The Ant Way"(tm) to have them as references, manipulated using custom tasks, and passed using reference semantic, and which unlike properties are not fully compartmented between Projects, which the parent and child project share the same referenced-object. Would installed PH instanced percolate to sub-Project automatically? Because if they do, Peter's argument that the explicit declaration of the PH ensures BC falls flat if one uses "external" reusable build files which would happen to use the same syntax as the PH prefix installed in another build file. That would be bad encapsulation. So the more I think about this, the more I feel it's wrong at several level. Let's stick with read access. As toString: demonstrates already, what's to the right of the PH scheme doesn't have to reference a property name, so it's flexible enough. --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
