I agree that property doesn't work well with macro and some other
use cases.
I'm +1 on local if we can keep it separated from property, so the
behavior of property doesn't change. I think it may be a good idea to
even throw an exception if some name is used with both local and property.
I wouldn't mind even a var that is local + modifiable.
I don't like the second example where local seems to be used to declare
filepath that is later defined as a property.
Another approach is to use namespaces for properties - IMO that's a cleaner
solution, but has the disadvantage that overloads property behavior.
( a local:foo property name will imply a local lifecycle, a att:foo could
be used for a modifiable property, etc ). I know this isn't very popular :-)
Costin
peter reilly wrote:
On Wednesday 22 October 2003 15:04, Stefan Bodewig wrote:
On 22 Oct 2003, Stefan Bodewig [EMAIL PROTECTED] wrote:
I haven't made up my mind on the feature itself
OK, re-reading the description first, I don't like the
,
| The value part of local is optional, and the local
| property may be set by a subsequent property, property
| will only set it if the value is not set.
`
part. This means that whenever I find a property task I'll have to
search all possible scopes for a local element and can't rely on it
being global.
What is the benefit of making property adhere to the scoping set up
by local?
The point is that all tasks including property see the local
properties as normal properties.
It means that the macro attributes are now seen as normal
properties by the tasks that are contained within the sequential
nested element.
The local makes a property of the same kind as the macro attribute.
A common use case for this is when converting an antcall to a macro:
I had a target that was used as an antcall target, it used a property
suite.pattern to contain a regex what was used a number of times
in the target and as an ant call was done to invoke the target, this
was not seen outside the target. On conversion to a macrodef, the
property suite.pattern is now a global property and the macrodef
may fail unexpectly.
With local the macro now looks like this:
!--
macro to generate test suites registing
@param gen.dir the dir to place the register_suites.h and .cpp
files @param unit.dir the dir that the unit_*.cpp files are located
--
macrodef name=gen-register-suites
attribute name=gen.dir/
attribute name=unit.dir/
sequential
local name=suite.pattern value=^ *SUITE\(.*,\s*(.*)\s*\)/
mkdir dir=${gen.dir}/
...
/sequential
/macrodef
Another common use case is use of a local to pass information from one
task to another without messing up global properties or similar properties
used in other targets (say in a complicated build with a number of imports
and lots of targets).
local name=filepath/
pathconvert property=filepath targetos=unix
refid=files.path/
echothe files in files.path are ${filepath}/echo
However I can see the problem of looking at a script and not knowing if
the property is local or global.
The last patch allowed [sub]ant[call] to inherit the local properties.
I propose to change the local so that this inheriatance is removed and
also that macro instances do not inherit the local properites - i.e.
the local properties are staticlly scoped in the build script.
So currently the following is the case:
property name=p value=global/
macrodef name=inner
sequential
echop is ${p}/echo
/sequential
/macrodef
macrodef name=outer
attribute name=p/
sequential
inner/
/sequential
/macrodef
outer p=from macro/
Will generate p is from macro which is probally not expected as
inner was not explicilty passed the property by outer and inner
may be in another file or in an antlib.xml.
Peter
I don't have any strong objections against the rest or the
implementation.
So +0.5 (which can be turned into a +0.9 by explaining why property
should care about scopes 8-).
Stefan
-
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]
