That's great! That sounds like the best approach. Configuration on such a specific matter is icky. Just makes it all more confusing. Better to pick the best convention and run with it.
WILL On Wed, Sep 21, 2016 at 2:38 PM, Claude Brisson <cla...@renegat.net> wrote: > The sharing convention is already in place since I applied Jarkko's patch > from VELOCITY-841 (which I applied in commit 1753788). You're right, I > think we don't need to go further. > > So I guess we're ready for the release! > > > Claude > > > > On 13/09/2016 23:40, Nathan Bubna wrote: > >> Since you're soliciting opinions, i have to say that we should probably >> just fully adopt Java's call-by-sharing semantics and not bother with a >> configurable argument evaluation strategy for macros. I suspect that a >> shift to call-by-sharing would not break the 90% of macros out there. I >> don't have evidence for that, but that's my suspicion. Velocity lives in a >> Java world, Java semantics and practices are easily spotted throughout VTL >> and VelocityTools as it is. I think the principle of least surprise >> dictates call-by-sharing and should make us confident that it will be an >> easy transition. Or does anyone actively want some variety of call-by-name >> for macros? >> >> Though, of course, y chief opinion here, as it has been for decades, is >> that those who do the work make the decision. If you want this to be >> configurable, Claude, then go for it. >> >> As to localscope, that's deprecated in 1.7. Recall the move toward >> "explicit scope control"? I'm of the opinion that the only "implicit" >> scope >> in VTL should be the global one. Anyone wanting to get/set an exclusively >> local variable should do so explicitly (e.g. #set( $macro.foo = 'bar' ) >> and >> $macro.foo ). I do feel fairly strongly on this one, but as i'm not >> heavily >> using Velocity any more, i can hold my peace if things go otherwise. If >> you're content with explicit scoping, it is probably worth reconsidering >> whether macro.provide.scope.control should still default to false. I was >> never quite certain about that default when i implemented it. >> >> And Claude, thanks again for all the work on this. Velocity may not be >> critical to my work these days, but it is still good to see it being >> updated. >> >> On Tue, Sep 13, 2016 at 11:23 AM, Claude Brisson <cla...@renegat.net> >> wrote: >> >> It may be the last big subject to address before releasing 2.0: how to >>> handle macro arguments? >>> >>> Those three issues exhibit nasty side effects of the current behavior: >>> >>> https://issues.apache.org/jira/browse/VELOCITY-683 >>> >>> https://issues.apache.org/jira/browse/VELOCITY-684 >>> >>> https://issues.apache.org/jira/browse/VELOCITY-752 >>> >>> There also is a great wiki page on the subject: >>> >>> https://wiki.apache.org/velocity/MacroEvaluationStrategy >>> >>> As for space gobbling, the correct behavior is probably to have a >>> configuration parameter (something like 'velocimacro.evolution.strateg >>> y', >>> which would take values like 'macro', 'relaxed' for the current behavior, >>> and 'sharing'). Also, we ought to avoid making a difference between >>> string >>> literals and other literals. >>> >>> But I'd appreciate to hear your thoughts on the subject. Especially: >>> >>> - how should the local scope, if present, affect the sharing mode? >>> >>> - how should the macro mode behave if one tries to assign a value to an >>> lvalue? >>> >>> >>> Claude >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org >>> For additional commands, e-mail: dev-h...@velocity.apache.org >>> >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org > For additional commands, e-mail: dev-h...@velocity.apache.org > >
