Serge Knystautas wrote:
On Wed, Oct 15, 2008 at 6:57 PM, Byron Foster <[EMAIL PROTECTED]> wrote:
Hmm, well if it means anything I would vote for 1. I think adding
another config option is contributing to option soup. And I think
the majority of users, even experienced users aren't really going
to want to consider the implications of strict pass by name. With
1) there is an option for those who are really effected by 285.
The example with x1 and x2 and $x was helpful in understanding the
problem. Could someone put option 1 and 2 in terms of how it would
affect that example?
Given the VTL:
#macro(dig $x)
x1: $x
#foreach($i in $x)
x2 $x
#dig($i)
#end
#end
#dig([[1,2],[3,4]])
option 1) (Which Nathan applied) will cause $x at x1: and at x2 to
render to two different values on at least the second recursion to dig.
This essentially rolls back the behavioral change in VELOCITY-285, but
provides a hook that allows developers to get back to option 2 behavior
if they depend on it...
option 2) $x at x1: and x2: would render to the same. But a config
property would be added to get option 1 behavior.
It's really just a question of what is the default behavior. My
personal feeling is that option 1 is the correct behavior for pass by
name, and so it is consistent. I think pass by name can be confusing,
but it is certainly compounded by adding special cases that modify the
behavior.
I mean to, but havn't gottten to it yet, modify Velocity so that it is
pass by value, and find how many test cases I break. I would be curious
to see how much of a shift this would be for Velocity.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
