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!


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( $ = 'bar' ) and
$ ). 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

On Tue, Sep 13, 2016 at 11:23 AM, Claude Brisson <> 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:

There also is a great wiki page on the subject:

As for space gobbling, the correct behavior is probably to have a
configuration parameter (something like 'velocimacro.evolution.strategy',
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


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to