At 08:05 PM 11/27/2001 +1100, Peter Donald wrote:
If I was the user and I had fubared my build setup then I would want to know as early as possible.
Sure, but how is your setup fubared here? What is the downside for the user if they don't follow exactly the developers' vision of what a property should be?
I would agree with you if the property-changing behaviour of <available> ran counter to most peoples' expectations of how it would work, but I doubt anyone here would make that claim. Would they? It seems obvious to me that having <available> fail to set the property would create much more confusion among users than the current behaviour.
Again, this is just my preference. I can see the arguments in favour of making the change.
Interesting idea ... needs exploration - I suspect it will be too complex. However the real problem is that ant1 is not fully capable of dealing with mutable properties and such a technique would need to wait till ant2.
I'm not suggesting any change to code here. You already have a system that matches up to what I described, although it doesn't enforce the policies through code. I'm just talking about changing the design perspective on what a property is by expanding to two types. I'm trying to make it clear why it is still good design for your current system to have some properties that can be changed by certain select tasks.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
