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]
