[
https://issues.apache.org/jira/browse/VELOCITY-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12667773#action_12667773
]
Byron Foster commented on VELOCITY-687:
---------------------------------------
<qoute>
it will add complexity to internal code that is already quite complex
</qoute>
I've attached the changes as a patch so the complexity can be assessed. I
believe them to be slight. The pass by value logic is simpler compared to the
code required to support pass by name.
<qoute>
It will add complexity to development and use of velocimacro libraries
</qoute>
I don't see this. The main intent of this approach is to provide a more
predictable and intuitive behavior to macros. I think this follows a precedent
set by the language world which has already travelled this road long before
Velocity. I suspect that most developers who write #do($foo.bar) are thinking
pass by value, rather then what is really going on. However, people who are
more comfortable with pass-by-name can simply not flip this switch.
<qoute>
it will add complexity to helping macro users on the mailing list, as it adds
another setting to ask them about.
</qoute>
That is possible.
<qoute>
It changes a very longstanding Velocity behavior
</qoute>
As a configuration switch, yes. However, I don't believe that because
Velocity has done something for a along time makes it right, wrong or
otherwise. I suspect that this behavior was simply carried over from the early
days, rather then a carefully considered design criteria.
<qoute>
it doesn't really added any needed new feature.
</qoute>
I think it adds an easier to understand parameter passing model. This may be
subjective, but again I point to the trend set by the language world. There
are parameter passing use cases that now become more useful (such as #foo([$a,
$b, $c]) and that are not laden with hidden gotchas. There are potential
performance increases, for example the benchmark in the experimental directory
runs 5-10% faster.
I would argue that for velocity 2.0 this should be the default behavior.
Adding this as a configuration parameter provides an opportunity to try this
out without committing.
> Macro pass by value option
> --------------------------
>
> Key: VELOCITY-687
> URL: https://issues.apache.org/jira/browse/VELOCITY-687
> Project: Velocity
> Issue Type: New Feature
> Components: Engine
> Affects Versions: 1.7
> Reporter: Byron Foster
> Attachments: value.patch
>
>
> Add a configuration property which would change macro parameter passing from
> pass by name, to pass by value. I think in many instances this option will
> provide behavior that is more intuitive to the user. There are two important
> exceptions to this, references created by #define, and references created by
> BlockMacro's $bodyContent. This allows the user to still specify pass by
> name semantics when desired, for example:
> #define($x) #if($foo)$foo.bar#{else}-None-#end #end
> #go($x)
> In the above example '#if($foo)$foo.bar#{else}-None-#end' will be passed by
> name. In all other cases pass by value rules apply for example:
> #go($foo.bar [1, 2, 3] #if($bar)Yes#{else}No#end)
> In the above example all parameters will be evaluated to a value first, then
> passed to #go. This has potential performance improvements also.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
