Hi Costin,
The idea is to make local properties appear
like normal properties.
Using something like "local:foo" to designate
local properties could be possible, however one
whould need to handle scoping issues like:
<sequential>
<property name="local:x" value="outer x"/>
<property name="local:y" value="outer y"/>
<sequential>
<property name="local:x" value="inner x"/> ? new local here ?
<echo>local:x is ${local:x}</echo>
<echo>local:y is ${local:y}</echo>
</sequential>
</sequential>
Both the <local> task and the <local> container make the scoping
explicit.
Peter
p.s.
It would be nice to get an example of property chaining
in the unit tests to make sure that the modifications
to PropertyHelper do not break property chaining.
On Thursday 23 October 2003 06:55, [EMAIL PROTECTED] wrote:
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
