> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> On Thu, 21 Oct 2004, Jose Alberto Fernandez
> <[EMAIL PROTECTED]> wrote:
>
> > How about structuring this local variables scope as follows:
> >
> > <propertyscope>
> >
> > <propertyscope>
> > <property name="1" scope="local" value="A"/>
> > <property name="2" scope="super" value="B"/>
>
> I don't see any use for the super scope myself, but if it
> helps to reach consensus ...
>
I kind of based the model in BeanShell's scopes. This is in part why
"super" was added. Maybe "super" is not the right name as it conveys
some sort of inheritance. Maybe "parent" is better (open to
suggestions).
Now, the point of this declaration, is that the property will be
available
outside the <propertyscope> but not necessarily made global. If we think
of macros caling other macros, having just local and global is a little
lacking.
> > And it cover all the cases of prefix and such by only modifying a
> > couple of places.
>
> Mainly <property> and <propertyset> - any other tasks?
>
> Infrastructure would be the same as for the latest local
> properties proposal, right?
>
> > Now, I still will fight until convinced the implementation does not
> > break some BC assumption. :-P
>
> The best thing to do is to list all your concerns, write unit
> tests for them and commit them to Ant's tests before the
> local patch goes in
> ;-)
>
A big task as there are 3rd party tasks that I do not even know about.
I think the approach here would have to be more in the sense of
what can be expressed with the current Java APIs (using <script/>)
for example. And check whether this changes will preserve the meaning
of what people can write. If there are changes in the meaning, then
we will have to evaluate its effects in backward compatibility.
> > You still need a way to shadow a property without defining it
>
> True.
>
> > (maybe scope="shadowed"?).
>
> I'm afraid this would overload the scope attribute of your
> proposal. Which scope is the property going to end up in once
> it gets defined? shadowed-super?
>
You are right. I am not sure what is the best way to do it.
One could say, if no "value" (or equivalent) is specified,
then you are shadowing. That may leave "environement"
properties not easy to shadow. It is a problem that the solution
whatever it is, must take into account. Maybe, <propertyscope>
should deal with this particular case of prefix based shadowing:
<propertyscope shadow="foo.">
<shadowset><!-- This defines a propertyset to shadow --></shadowset>
</propertyscope>
These are two different suggestions, do not know whichone is best.
As per where you shadow, you always shadow locally, that is if I
ask <isset property="foo"/> this will always look locally to see if
${foo} is defined. Now, as the rules for modifying properties have
not change. Whether assigment of a value to a property in "parent/super"
or "global" scopes takes effect, will depend on whether they are already
defined in those scopes or not.
I would like to hear comments about having an "antlib" scope. I.e.,
global but visible only to tasks defined in the same antlib. This
will give you a concept similar to "module variables" in many
programming languages.
Jose Alberto
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
