Re: Vote: for 1.6

[Christopher Lenz]

peter reilly wrote:
On Wednesday 29 October 2003 12:06, peter reilly wrote:
On Wednesday 29 October 2003 10:42, Stefan Bodewig wrote:
On Fri, 24 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
  <ac:if>
     <equals arg1="a" arg2="${prop}"/>
     <then>
        blab ...
      </then>
      <else>
        blab..
      </else>
  </ac:if>
Assuming Ant's core URI was associated to the default namespace, you'd
have to use ac:then and ac:else.
This is not the current ant 1.6 behaviour. All elements belong to
the core URI, except typedef'ed elements and whatever the user
wants to pass to DynamicConfigurable#
To change this would require (tricky) modifications to UnknownElement.cpp
and IntrospectionHelper.cpp.
Ok, the changes are not too tricky.
However I am not too sure I like going from:
  <cpp:compiler id="compiler.options" extends="compiler.flags">
    <defineset>
      <define name="_NO_SNMPv3"/>
      <define name="D_GNU_SOURCE" value="1"/>
      <define name="linux" value="1"/>
      <define name="PETER_BUILD" value="1"/>
    </defineset>
    <includepath location="${src.dir}"/>
    <includepath location="${src.dir}/include"/>
    <includepath location="${cdk.dir}/src/include"/>
    <sysincludepath location="${snmp++.dir}/include"/>
    <sysincludepath location="${agent++.dir}/include"/>
    <sysincludepath location="${log4cpp.dir}/include"/>
    <sysincludepath location="${sigc++.dir}"/>
    <sysincludepath location="${boost.dir}"/>
    <sysincludepath location="${libedit.dir}"/>
    <sysincludepath location="${thirdparty.dir}/dist/include"/>
  </cpp:compiler>
to
  <cpp:compiler id="compiler.options" extends="compiler.flags">
    <cpp:defineset>
      <cpp:define name="_NO_SNMPv3"/>
      <cpp:define name="D_GNU_SOURCE" value="1"/>
      <cpp:define name="linux" value="1"/>
    </cpp:defineset>
    <cpp:includepath location="${src.dir}"/>
    <cpp:includepath location="${src.dir}/include"/>
    <cpp:includepath location="${cdk.dir}/src/include"/>
    <cpp:sysincludepath location="${snmp++.dir}/include"/>
    <cpp:sysincludepath location="${agent++.dir}/include"/>
    <cpp:sysincludepath location="${log4cpp.dir}/include"/>
    <cpp:sysincludepath location="${sigc++.dir}"/>
    <cpp:sysincludepath location="${boost.dir}"/>
    <cpp:sysincludepath location="${libedit.dir}"/>
    <cpp:sysincludepath location="${thirdparty.dir}/dist/include"/>
  </cpp:compiler>
one solution would be to allow both.
Allowing both doesn't look like a good idea to me, and I agree with Stefan 
that the first example seems incorrect from an XML point of view.

To remove some of the verbosity of your second example, you could also use a 
local default namespace:

  <compiler id="compiler.options" extends="compiler.flags"
      xmlns="antlib:net.sourceforge.cpptasks">
    <defineset>
      <define name="_NO_SNMPv3"/>
      <define name="D_GNU_SOURCE" value="1"/>
      <define name="linux" value="1"/>
      <define name="PETER_BUILD" value="1"/>
    </defineset>
    ...
  </compiler>
In an earlier thread I proposed the general rule that if a namespace'd task 
or type defines the names of introspection-discovered elements, those 
elements inherits the namespace from its parent.

Consider this pseudo task class:
  MyTask {
    addFoo(Bar foo);
  }
This task obviously defines the name of the nested element, so the namespace 
is inherited. Now if MyTask is in the namespace "my", we'd need to write:

  <my:task>
    <my:foo/>
  </my>
The same would apply if the nested "foo" element was not 
introspection-discovered, but rather created via DynamicConfigurator, 
because the task or type implicitly defines the name of the nested element 
in that case. It may have a if (name.equals("foo")) in the code, for example.

Now, if the task class looked like:
  MyTask {
    add(Bar bar);
  }
...and Bar would be type defined with the name "foo", also in the "my" 
namespace, we'd still write:

  <my:task>
    <my:foo/>
  </my>
In this case the name of the nested element is not defined by MyTask, it is 
defined when "foo" is typedef'd. However, it is defined with the same 
namespace URI as MyTask, so while the prefix is not inherited it is the same 
as that of its parent element.

Now *if* the "foo" type was defined in the default Ant namespace, we'd have:
  <my:task>
    <foo/>
  </my>
Because MyTask does not define the name of the nested element, and "foo" was 
not defined with the default namespace URI.

IMHO this rule is clear and logical. Or am I missing something?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]