Re: Macro arguments

2016-09-24 Thread Will Glass-Husain 
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  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 
>> 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
>
>

Re: Macro arguments

2016-09-21 Thread Claude Brisson 
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  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.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
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

Re: Macro arguments

2016-09-13 Thread Nathan Bubna 
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  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.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
> lvalue?
>
>
>   Claude
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>