Thanks a lot for this very useful and clear information. I am surprised to read that <available> can override properties. Is there a reason for it? Patrick M.
On 2/16/06, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > On Wed, 15 Feb 2006, Patrick Martin <[EMAIL PROTECTED]> wrote: > > > Could you explain the "even more immutable" part of your mail ? > > Sure. > > Properties are not immutable at all if you use Ant's Java API. It's > just that (almost[1]) all of the built-in Ant tasks refuse to change > the value of an existing property. But it is trivial to write a task > that changes the value of a property and in fact a lot of people and > projects have done so. > > There are five property setting methods in Ant's Project class: > > setNewProperty - sets a property, will never override an > existing one - user property or not. > Used by almost all built-in Ant tasks. > setProperty - sets or overrides a property, will never override > a user property. Used by <available>. > setPropertyInternal - same as setProperty but without any warning if > it overrides a property. > setUserProperty - sets or overrides a user property. Used when > parsing the command line. > setInheritedProperty - sets or overrides a user property. Used for > <property> nested in Ant. > > So both "plain properties" and "user properties" are in fact mutable > if you use the Ant API. Only one of the five setter methods will not > overwrite an existing property, only two of them will overwrite an > existing user property - which makes user properties "more immutable". > > Stefan > > Footnotes: > [1] Since I know I'll have to explain the "almost", <available> will > happily overwrite existing properties. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
