> From: Peter Reilly [mailto:[EMAIL PROTECTED] > > Stefan Bodewig wrote: > > >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: > > > > > >>>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. > > > Jose's solution could be modified to remove the properties on > exit from the macrodef. - but this would need to be made thread-safe. >
Notice, that except for the access to the HashMap containing the properties you do not need to do much more in the sense of thread safety. The names are unique, hence there is no two threads with the same property (unless the name gets passed from a common parent) but in that case, the parent is the one that should remove the name. BTW, let me just stress again, that my approach can be also used for other things like for example: references. Is there a way to define local references in a macro today? It is up to you to decide what you want to use the new name for. And in that sense it would be also up to you to specify for it to be cleaned afterwards. This is the main reason why I did not impose a particular scope semantics. Jose Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
