On 05/02/2010 09:01 PM, Caleb James DeLisle wrote: This only affects things like this: #macro(m $returnParam) #set($returnParam = 'result') #end #m($expectedOutput) $expectedOutput is not 'result' These will still work: #macro(m) #set($returnParam = 'result') #end #m() $returnParam is 'result' Or: #set($output = {}) #macro(m $output) $output.put('expectedOutput1' : 'result1') $output.put('expectedOutput2' : 'result2') #end #m($returnParam) $returnParam.expectedOutput1 is 'result1' $returnParam.expectedOutput2 is 'result2' The first one is not nice since it has side effects which must be well documented, the second one is nicer but also needs to be documented and it needs a map or array even if only one output is expected. The way velocity macros work is a bit unclear, it's a mix between call by macro expansion, call by sharing, call by value and other behaviors. See http://en.wikipedia.org/wiki/Evaluation_strategy and http://www.knowledgerush.com/kr/encyclopedia/Call-by-something/ for short explanations. Call by sharing example (in 1.7b1 only) #macro(callBySharing $x $map) #set($x = 'a') $map.put('x', 'a') #end #set($y = 'y') #set($map = {}) #callBySharing($y $map) $y -> 'y' (but is 'a' in 1.6.2) $map.x -> 'a' Java-like behavior Call by name/macro expansion example (and call by need counter-example) #macro(callByMacro1 $p) not using #end #macro(callByMacro2 $p) using: $p using again: $p #end #set($x = []) #callByMacro1($x.add('t')) $x -> [], the add call was not executed #callByMacro2($x.add('t')) $x -> [t,t], the add call was executed twice Call by value(?) example (and call by name or expansion counter-example) #macro(callByValueSwap $a $b) $a $b becomes ## #set($tmp = $a) #set($a = $b) #set($b = $tmp) $a $b #end #callByValueSwap('a', 'b') -> a b becomes b a In a true call-by-name (or macro-expansion) implementation, $a would always be 'a'. What actually happens is that #set($a = $b) creates the global variable $a which shadows the formal parameter. Call by macro expansion example (and call by value or sharing counter-example) #macro(changeMap $map) Before: $map.someKey #set($map.someKey = 'new value') After: $map.someKey #end #changeMap({'someKey' : 'old value'}) -> old value, then again old value If this was true call-by-sharing (or call-by-reference), then $map would be a pointer to a real map which would be changed by the first set. Call by macro expansion example (exposes name capture, call by name counter-example) #macro(nameCaptureSwap $a $b) $a $b becomes ## #set($tmp = $a) #set($a = $b) #set($b = $tmp) $a $b #end #set($x = 'a') #set($tmp = 'b') #nameCaptureSwap($x $tmp) -> a b becomes a a This is the classic name capture example, which only happens with call by macro expansion. In conclusion, Velocity macros work mostly as call-by-macro expansion internally, with call-by-sharing external behavior, but affected by automatic assignment of global variables when local variables can't be assigned. -- Sergiu Dumitriu http://purl.org/net/sergiu/

On 05/03/2010 04:48 AM, Caleb James DeLisle wrote: All except the first one, pass by sharing, which is the one causing us trouble. -- Sergiu Dumitriu http://purl.org/net/sergiu/