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"/>
> <echo>the 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>
> <echo>p 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]
