ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <jakarta-...@ehatchersolutions.com>
Subject Re: Immutability
Date Sat, 08 Dec 2001 00:46:53 GMT
----- Original Message -----
From: "Stefan Bodewig" <bodewig@apache.org>
To: <ant-dev@jakarta.apache.org>
Sent: Friday, December 07, 2001 10:13 AM

> Didn't mean to imply that (yes, I've seen the smiley 8-).  "This is
> going to make Ant a procedural language" has been used to kill
> discussions all over the place (by my self as well), that's all.
> Effectively it can be used to end a thread, so it can be used for the
> same purpose as Godwin's Law, that's all.

Understood.  I'm not trying to kill this thread... its actually dying down
on its own because decisions have been made on how it'll be for Ant 1.5 at
least.  I'm cool with it as is, except for the <available> inconsistency.

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

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

Taglibs have the ability to find their parent tags, getParent(), and even
find a specific ancestor tag by class, findAncestorWithClass.

A task that could do something similar could find out if its in a
container - getParent() instanceof TaskContainer - and default values or
error depending on its needs if not within a container.

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

Rather than making it a "property" per se, it could just be a member
variable of the TaskContainer... getParent().getCurrentIteratorValue().  But
certainly communication via properties (aka attributes in JSP-speak) is one
of the powerful features of JSP, and they are scoped in several categories
(application, session, request, page, and scripting contexts).  This analogy
falls apart a bit because anyone at anytime can change any values in any
scope it has access to - but maybe thats the key - "that it has access to".

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

Even with the core enforcing immutability, <antcall> could be used, and this
seems like a good use of it actually since changing compilers is a pretty
non-standard thing to do I would think.

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

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.

But I trust there are some use-cases out there for such situations.

    Erik



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