> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > On Mon, 1 Dec 2003, Jose Alberto Fernandez <[EMAIL PROTECTED]> > wrote: > > > Well now that we are finally getting to an agreement > > on <macrodef> I think it is time to start a new round > > of rocous over <local>, (not enough traffic today ;-P ) > > We don't seem to be too successful in generating responses > these days. 8-) > > I'm a bit torn between releasing 1.6 without any local > support and trying to get enough support for it to delay 1.6 > further. I think local is necessary to make macrodef as > powerful as it should be, but wouldn't want to wait another > two months to finally get committer support for it into 1.6. >
I think we should release without <local>. And I think we could add local as an add-on later (do not think we need to wait for 1.7, if we design it properly). > > I still fill a little unconfortable on using <local> > > for defining local-scopes (which was the original usage) > > and using <local> to define values that must be different > > on different threads of execution (i.e., Java ThreadLocals). > > Hmm, > > <parallel> > <sequential> > <local property="a"> > ... > </local> > </sequential> > <sequential> > <local property="a"> > ... > </local> > </sequential> > </parallel> > > should give something predictable - or something that is > completely undefined, much like what we'd currently have for > references. > > The above looks like a "user's fault" situation, until you > let <macrodef>'s using <local>s into the game. > > <macrodef name="foo"> > <sequential> > <local name="my-temporary-variable"> > ... > </local> > </sequential> > </macrodef> > > with multiple invocations of <name> inside <parallel>. For a > scenario like this, <local> implicitly promises to be Thread > local. At least it does for me. > > 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]
