> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> 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.
>
I just want to say that in my proposal, the temporary properties only
last for as long as the Project instance is executing. Once we leave the
scope
of the project the properties will disappear.
Hence we are not talking about unbound existance for the life of the
JVM.
AFAIU, IDEs and other tools that execute ANT within the same VM do not
keep properties of the main project set for the entire life of the JVM
properties come to existance and disappear during the live of the
execution of
the Project instance. There are no different rules here.
The only thing that last for the life of the JVM is the long counter
used
to generate names, but I doubt that can be seen as an issue.
> > 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.
>
How do you use <local/> in conjunction with <condition/>?
For this to work, you need a way to declare the property without
defining it, but shadowing any previous definition of such property.
Otherwise, it is not possible to use tasks that either set/notset
a property depending on the execution of some task. Or do we need to
modify all those tasks too, to deal with this new concept.
As per my proposal, if the extended life of properties is considered
such a major issue, I am sure the implementation can be easily changed
to remove the property once the scope of the <let> i.e., <macrodef/>
is exited. The reason I do not do it, is because <let/> does not define
a property, it just define a new name for one. And it is up to the usage
of
our regular tasks to decide to define it or not. But notice that one
could use the name created by let, for anything else, not just a
property.
But we could add a way to say, "clean any property of this name on
macrodef exit",
that would be quite easy to do, I think.
> > 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?
>
If the name use to refer in a macro to a property is the same as
the name used to physically represent it, and you want to write a
recursive
macro, you will have the shadowing problem (as in any other programming
language) That is why we have local scopes and in any programming
language
names are indirect pointers to locations and not locations themselves.
You will have the same issues here. Lets face it our current
datastructures
for properties are no better that variables in Cobol68 and we know how
limitted is recursion in such old languages.
> > 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.
>
The life is that of any other property defined in ANT. If such
properties
continue living beyond buildFinish() then the whole NetBeans environment
would be useless, isn't it? You could not use "if" in targets as the
value
would be set once and any future execution would not reevaluate.
Since I do not think that is the case in any workable environment,
I see no problem what so ever.
> > 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.
>
It will have to touch more and more things. For example how do
you define a local property to be set by a <condition/>
You will either have to alow <local> to have a nested condition,
or modify condition to understand <local>. But then you have
all other tasks that set properties if something happens. You
will have to change them all too. And the list goes on and on and on.
Jose Alberto
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
