Yeah, sorry. I forget about that, since i've been avoiding macros for some time and never actually bothered with this property:
velocimacro.context.localscope = true On Thu, Feb 21, 2008 at 9:59 AM, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > Wait - that's not true.... You certainly can do scoped velocimacros... > > geir > > > > On Feb 21, 2008, at 12:57 PM, Nathan Bubna wrote: > > > On Thu, Feb 21, 2008 at 6:36 AM, Christopher Schultz > > <[EMAIL PROTECTED]> wrote: > >> Nathan, > >> > >> > >> Nathan Bubna wrote: > >>> I'm pretty sure #local is still just in Geir's whiteboard > >>> section. No > >>> one has ever gotten it promoted out of there. I've never been > >>> opposed > >>> to it, but i've also never been interested in putting the work > >>> needed > >>> into it (tests, docs, etc). > >> > >> I have to admit that when I started really writing macros (other than > >> super simple ones), I was disappointed to learn that there was no > >> "stack"... that is, I couldn't implement certain things properly > >> using > >> the macro facility because recursive calls would overwrite variables > >> from what I would have considered "outer" scopes. > >> > >> If anyone is contemplating a "Velocity 2.x", I would seriously > >> recommend > >> that macros and other things (like #parse, #evaluate, and similar > >> things) run in their own, local and inherited contexts. This gives > >> much > >> greater freedom to the developer, who doesn't have to worry about > >> "temporary" variables within macros, etc. clobbering variables set in > >> the caller's scope. > >> > >> It would be best if this were simply a language feature, instead of a > >> hack provided through another directive (though it would have to be > >> hacked in this way for Velocity 1.x, since some folks may actually > >> rely > >> on this inconvenient setup. > > > > inconvenience is sometimes a matter of perspective, and you might soon > > find people providing special #setglobal hacks for when they do want > > to clobber a variable in the caller's scope. personally, i've always > > been able to see this both ways and never had much trouble adjusting > > to the lack of scoping. when my macros/layouts/parses ever get > > complicated enough that i can't track all the variables, i just start > > namespacing ones i want to keep 'local'. > > > > anyway, being able to see both sides and easily adjust either way, you > > probably won't ever find me motivated to work on this or object to > > anyone else working to change this in a theoretical 2.x version. > > namespaces or scoping, i'm good either way. :) > > > >> -chris > >> > >> > > > > > > --------------------------------------------------------------------- > > 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]
