Stefan Bodewig wrote:
Trying to consolidate a few answers since I'm very late to the party anyway.
On Fri, 08 Oct 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
I have had a proposal outstanding for a while for local properties:
a long while.
My preferences haven't changed much over time, but I'm far too busy to help getting this to a conclusion. My current work schedule would prolong any kind of discussion for an unreasonable amount of time.
I think we need to address the problem of temporary properties inside macros in some way and prefer a solution that doesn't leave us with tons of new and unused properties. If I can't get it my way, read "if I can't convince you", I'd rather see your solution implemented than keep the status quo.
1) Syntax The proposal adds a local property to a enclosing target/taskcontainer.
Example: <target name="example"> <local name="prop" value="a local value"/> <echo>prop is ${prop}</echo> </target>
<macrodef name="t2"> <attribute name="file"/> <sequential> <local name="dir"/> <dirname property="dir" file="@{file}"/> <mkdir dir="${dir}"/> <touch file="@{file}"/> </sequential> </macrodef>
I think it is nicer to do this rather that having an explicit local property container,
Nicer? Maybe. I still think a special task container would be cleaner since it provided explicit scoping and might even help us route around the "custom PropertyHelpers problem". Something like
<target name="example"> <let> <local name="prop" value="a local value"/> <echo>prop is ${prop}</echo> </let> </target>
but I'm repeating myself. I have no new arguments to add.
Since we are really only worried about the macrodef usecase, we could initially just deal with this using the syntax:
<macrodef name="t2">
<attribute name="file"/>
<localproperty name="dir"/>
<sequential>
<dirname property="dir" file="@{file}"/>
<mkdir dir="${dir}"/>
<touch file="@{file}"/>
</sequential>
</macrodef>I.e have a local nested element for <macrodef> - this syntax has of course been discussed previously. We can leave the gate open to allow other third-party containers to use local properties - like the <let> container in your example, or the <for> task from ant-contrib or the <foreach> task from antxtras. This could be done by providing the java api to create localproperties. Implementing all containers to support local properties could be at a later stage - if there is a demand (unlikely).
The local properties should I think be in thread-local storage to avoid conflicts between multiple threads, so I think that PropertyHelper needs to be modified to do this.
2) Shadowing of properties
The proposal allows local properties to shadow normal and user properties. I feel that this is necessary to allow macrodefs to be written without them failing sometimes.
Can you expand on this please? Whyt kind of macros would require shadowing in order to be writable?
There are two reasons for this
1) Macrodefs are normally hidden - say in imported files or in an antlib, so one may not know what names they use for local properties. Normal programming languages allow scoped variable names to override the global names to allow this isolation. If user properties names overrode the localnames, the <t2/> example above would really not be able to use a nice small name like "dir" for the localproperty name, but would have to adopt a convention like "t2_dir" for the name, and hope that no one will use ant -Dt2_dir="not a nice dir". Jose's approach does not have this problem - but it does come at a cost (hidden names).
2) the user explictity say that the name is a local property. It seems
reasonable to expect that the property that is used is local and not a global
property (this is probally the same argument as 1) :-[ )
3) Extent of local properties
local properties will be inherited to child projects (if inheritall is true).
Fine with me.
On Fri, 8 Oct 2004, Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote:
2) All these uniquely named properties go on living after the macro has executed. That pollutes the namespace.
Yes it does. But I still have to see a good argument on why shall that bother anyone. Unless you are talking about millions of executions within one project context.
Hmm, ask Steve how long a SmartFrog instance is running. And AFAIU NetBeans 4 runs a single instance of Ant as long as the IDE is running. This may really lead to quite a few properties at the end of the day, in particular if you need to pass them to a forked JUnit VM or down to a child build with inheritall set to true.
Jose's solution could be modified to remove the properties on exit from the macrodef. - but this would need to be made thread-safe.
I do not agree, but like I said above this is not needed for the macrodef use case
My worries with these other solutions are that they not only touch macrodef and propertyHelper, they modify target, ant, sequential, parallel,and several other tasks.
That's why I'd prefer the explicit TaskContainer. It shouldn't be necessary to touch target, for example.
so it can be dropped from the proposal.
Peter
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
