https://issues.apache.org/bugzilla/show_bug.cgi?id=42046

Jesse Glick <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]

--- Comment #8 from Jesse Glick <[email protected]> 2012-02-08 16:40:36 UTC 
---
Due to regressions like that described in bug #52621, probably this fix needs
to be opt-in, since I can imagine various other scenarios where the former
behavior (call by value) is wanted and a change (call by name) would be
incompatible.

Suggest introducing an attribute on macrodef like 'expands' which would be true
by default; those users who have struggled with double expansion in the past
can explicitly set it to false, but others would be unaffected:

  <macrodef name="echotest" expands="false">
    <attribute name="message"/>
    <sequential>
      <echo message="@{message}"/>
    </sequential>
  </macrodef>

RuntimeConfigurable.java would then read:

if (target instanceof MacroInstance &&
    !((MacroInstance) target).getMacroDef().isExpands()) {
  attrValue = value;
} else {
  attrValue = PropertyHelper.getPropertyHelper(p).parseProperties(value);
}

With a slightly more complex patch, the <attribute> nested element could
individually have an expansion attribute:

  <macrodef name="echotest">
    <attribute name="message" expands="false"/>
    <sequential>
      <echo message="@{message}"/>
    </sequential>
  </macrodef>

(Not sure if the same consideration applies to <text> and/or <element>.)

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to