ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <jalbe...@cellectivity.com>
Subject RE: [new tasks] presetdef and macrodef
Date Thu, 21 Aug 2003 10:56:17 GMT
> From: Gus Heck [mailto:gus@cognition.olin.edu] 
> 
> Jose Alberto Fernandez wrote:
> 
> >Dominique,
> >
> >As its name indicates <macrodef/> is a MACRO. And macros are 
> macros are 
> >macros and they are suppose to be textually replaces at the point on
> >invocation.
> >  
> >
> Of course the parameters need to be replaced. The point is they 
> shouldn't look like properties. This way they can't be confused with 
> properties.  An alternate form to ${foo} is all that is needed. Just 
> search for a diferent pattern... {@foo} or (@foo) or @{foo} 
> or %{foo} or 
> $[foo] or really anything that isn't ${foo}. Dominique did also point 
> out that (@foo) and {@foo} are already commonly used in other 
> contexts 
> that build authors will be familliar with.
> 

I have no big issue on which syntax is used on each case, but I just
would
like to point out that there are actually 3 types of properties that
need 
to be taken into consideration:

 1) Properties to be expanded when the definition of the macro is found
    This is what Dominique wants "${xyz}" to mean, and I was looking for
    a syntax to express it.

 2) Attribute properties which are parameters on the call of the macro
    This is what people want to have a different syntax for, to
distinguish
    from the rest, it was proposed to use {@xyz} or (@xyz).

 3) Properties to be expanded at the time of the call from the
environment
    in which the call is made, this is what "${xyz}" means right now. As
a
    macro or template definition I need to have a way to refer to things
in
    the context of the expansion, so we need syntax for it.

So as you can see there are three diferent things here, that need to be
represented.
I really do not like inventing three diferent notations, if it can be
helped
in particular given the fact that we already have a ton of machinery in
ANT
that has been defined and seem to never being reused. Looking at all
this
machinery, it seems to me we could use the PropertyHelpers (Handles?)
infrastructure
to diferentiate between the cases, as follows (just an idea):

  (1) --> ${xyz}
  (2) --> ${macroattr:xyz}
  (3) --> ${macrotemplate:xyz}

So for a definition like:

  <property name="xyz" value="true"/>
  <macrodef name="abc">
    <attribute name="pqr"/>
    <sequential>
      <javac debug="${xyz}" ... />
      <javac debug="${macroattr:pqr}" ... />
      <javac debug="${macrotemplate:xyz}" ... />
    </sequential>
  </macrodef>

After this definition the macro that is actually expanded will look
something like:

    <attribute name="pqr"/>
    <sequential>
      <javac debug="true" ... />
      <javac debug="${macroattr:pqr}" ... />
      <javac debug="${xyz}" ... />
    </sequential>

which will be further expanded in a call frangment, maybe inside an
<ant> call:

  <property name="xyz" value="false"/>
  <abc pqr="true"/>
  <abc pqr="false"/>

To effectively finish executing the following ANT fragment:

    <property name="xyz" value="false"/>
    <sequential>
      <javac debug="true" ... />
      <javac debug="true" ... />
      <javac debug="${xyz}" ... />
    </sequential>
    <sequential>
      <javac debug="true" ... />
      <javac debug="false" ... />
      <javac debug="${xyz}" ... />
    </sequential>

So, as long as we can acomplish something like this, and we do not add a
bunch
of new machinery in the process, I think it is a wonderful feature.

Jose Alberto

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message