ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject Re: Immutability
Date Sat, 08 Dec 2001 01:24:15 GMT
From: "Stefan Bodewig" <bodewig@apache.org>

> On Fri, 7 Dec 2001, Erik Hatcher <jakarta-ant@ehatchersolutions.com>
> wrote:
> 
> > Could you provide an example just so I have something more tangible
> > to consider?
> 
> Appending to an existing path reference?  OK, this one just came to my
> mind after I've seen Conor's mail.
> 

Now, today you can do the append, you just cannot call it with the same name.
But why would you want to use the same name?

> > Struts has a <logic:iterate> tag that provides a scripting variable
> > within the scope of the begin and end tags.
> 
> If you use a construct like a TaskContainer scoped variable, tasks
> that are supposed to access them must be aware that they are nested in
> this type of construct.
> 
> If you allow these containers to create a "normal" property, change it
> during iteration and then remove it from the project when they are
> done, you can use the ${} mechanism (if this one is fully dynamic) and
> no extra coding is required.
> 

The problen here is that is not inmutability but the fact that, as I said before,
the current code has no concept of scoping, This would not be dificult to add
and can be done without affecting the behaviour (or coding) of tasks.

> 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.
> 

This is a defect of the <javac> tasks that use a "magic property"
as oppose to an attribute to make that decision. It can be easily fixed
by having a property like "compiler" which by default falls back
on the value of the "magic property". 
Not a goodargument for inmutability.

> * 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.
> 

This is a none sense example, sorry to say. In the current implementation
not even <antcall> can reuse the same Project object. 
There are many other things that need to be changed before such reuse 
of the Project structure can be done. So to blame inmutability
is just trying to pull a rabbit out os a hat.

> * reacting to a change in environment - things become availbale or
> unavailable.
> 

This is also a false example. If this where a real situation then I could say
we need to be able to re-evaluate dependencies because the environement
in which the dependencies where evaluated can change and dependencies 
can become out of date.

This are very contrived cases (in particular the GUI) that really do not seem
to be an argument for mutability.

Jose Alberto



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message