ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Immutability
Date Sat, 08 Dec 2001 01:29:27 GMT
On Sat, 8 Dec 2001 11:46, Erik Hatcher wrote:
> > Appending to an existing path reference?  OK, this one just came to my
> > mind after I've seen Conor's mail.
> Why not just create a new path reference id with the two appended together?

that would be way too logical. Using a different name to refer to a different 
object? Thats ludicrous ;)

> > For some other examples:
> >
> > * chosing the compiler on a task by task basis.  There are projects
> > where you need to compile certain classes with a different compiler
> > than the rest of the project.
> How would you do that currently since properties were always somewhat
> immutable except with backdoor tricks?  Use <available>?

You don't use properties but set attributes of task. So this need has already 
been satisfied.

> > * reusing the same project instance in an "incremental" mode or under
> > GUI control without reconstructing it.  Or even just building the
> > project instance from a build file and let the user use some wizard to
> > set property values in the GUI.

Yet why does that require properties to be mutable during the execution of 
project? Wait ... it doesn't.

> Well, I can't really speak to this one, but there are many  more issues
> with embedding Ant in IDE's and other systems than just property
> immutability I believe.  Certainly such integration is crucial to Ant's
> long-term success though and the Ant team should build these needed hooks
> into future versions in better and better ways.


> > * reacting to a change in environment - things become availbale or
> > unavailable.
> I can't even imagine why this is really needed, except for the case I saw
> posted recently with someone wanting to wait for a server to become
> available to deploy to it (or something like that) - and I believe that
> situation was handled with existing capabilities and didn't need to change
> property values - I think it was embedded in <condition>, IIRC.

Actually this is a need that we need to address. It has been brought several 
times in the past. The classical example being fileset. Sometimes you want to 
define the fileset at one point but not "evaluate" it till later. Is this a 
real need? Not sure but it has been asked for lots in various guises (see the 
recent live properties debate and the <tstamp/> discussion).

Last time we discussed this I think we decided that we would allow a 
"resolution" step. However this has nothing to do whether a value can be 
reassigned. The "resolution" step was agreed upon specifically because it did 
not require that reassignment occur.



 militant agnostic: i don't know, and you don't know either.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message