RE: macrodef - do attributes as properties or substitutions

[Steve Cohen]

True, that was from the 1.4/1.5 days.

-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 19, 2003 8:52 AM
To: 'Ant Developers List'
Subject: RE: macrodef - do attributes as properties or substitutions


> From: Steve Cohen [mailto:[EMAIL PROTECTED]
> I have used a similar idea with a build file full of "template" 
> targets that use a fileset reference.  The reference must be defined 
> globally or the build will break, but only some of the users of the 
> file of "templates" actually need the reference.  So, since references

> can be overridden, the solution is, similar to Stefan's,
> 
> 
> 
> 
> 
> Later, a user of this buildfile can redefine the globaltlds reference,

> if it needs to, to something real.

Yeah, this sounds a lot like the Null Object idiom you can read about in
Martin Fowler's Refactoring book. OTOH, now that there is the
 condition, a cleaner approach might be to conditionaly
execute the target only of the reference is defined at all, rather than
defining a null/dummy one. Probably not applicable all the time, but
still. --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: macrodef - do attributes as properties or substitutions

[Dominique Devienne]

> From: Steve Cohen [mailto:[EMAIL PROTECTED]
> I have used a similar idea with a build file full of "template" targets
> that use a fileset reference.  The reference must be defined globally or
> the build will break, but only some of the users of the file of
> "templates" actually need the reference.  So, since references can be
> overridden, the solution is, similar to Stefan's,
> 
> 
> 
> 
> 
> Later, a user of this buildfile can redefine the globaltlds reference, if
> it needs to, to something real.

Yeah, this sounds a lot like the Null Object idiom you can read about in
Martin Fowler's Refactoring book. OTOH, now that there is the 
condition, a cleaner approach might be to conditionaly execute the target
only of the reference is defined at all, rather than defining a null/dummy
one. Probably not applicable all the time, but still. --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: macrodef - do attributes as properties or substitutions

[Steve Cohen]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 18, 2003 2:06 AM
To: [EMAIL PROTECTED]
Subject: RE: macrodef - do attributes as properties or substitutions


> > 
> > 
> > 
> > 
> > 
> 
> I don't think we should need any special cludges just to support this 
> usecase. 8-)
> 
> Give two a completely bogus, impossible to be used in any real world 
> usage value and check for that.  Should be easier than comparing it to 
> a literal ${one} or @one or whathever.
> 
> 
> 
>
> default="nobody-with-a-sane-mind-would-ever-want-to-use-this-value"/>
> 

Nice idea - usually such nice words don´t come into my mind when I´m 
programming :-) But the string comparison would be easier.

Jan

I have used a similar idea with a build file full of "template" targets that 
use a fileset reference.  The reference must be defined globally or the build 
will break, but only some of the users of the file of "templates" actually need 
the reference.  So, since references can be overridden, the solution is, 
similar to Stefan's, 





Later, a user of this buildfile can redefine the globaltlds reference, if it 
needs to, to something real.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: macrodef - do attributes as properties or substitutions

[Jan . Materne]

> > 
> > 
> > 
> > 
> > 
> 
> I don't think we should need any special cludges just to support this
> usecase. 8-)
> 
> Give two a completely bogus, impossible to be used in any real world
> usage value and check for that.  Should be easier than comparing it to
> a literal ${one} or @one or whathever.
> 
> 
> 
>
> default="nobody-with-a-sane-mind-would-ever-want-to-use-this-value"/>
> 

Nice idea - usually such nice words don´t come into my mind when I´m
programming :-)
But the string comparison would be easier.

Jan

Re: macrodef - do attributes as properties or substitutions

[peter reilly]

On Monday 17 November 2003 15:57, Stefan Bodewig wrote:
> On Fri, 14 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:
>
> > An example:
> > 
> >   
> >
> >
> >
> >
> >
> >   
> >
> >   
> > 
> >   inmacro is '${inmacro}'
> > 
> >   
> > 
> > This shows:
> >
> > s:
> > inmacro is 'Set in macro'
> >
> > It would be very difficult to stop this.
>
> So we must ask outselves whether this is good or bad for us.
>
> If the property inmacro has been defined before the macro invocation,
> the task inside the macro will be a noop - the user gets the expected
> behavior.
>
> If it has not been set, well, this might come unexpected.

I suppose it depends on how one sees macrodef. Treated as
a simple macro substition:
 
 





 

 
   

   inmacro is '${inmacro}'
 
   


the target "s" would become:

  
   
   inmacro is '${inmacro}'
   

And the above will behave the same as the macrodef version.


>
> But there will never be any double expansion, right?  I mean,
>
>   inmacro is '$${inmacro}'
>
> would always result in
>
> > s:
> > inmacro is '${inmacro}'

Yes with the current implementation (not with some of my intermediate
implementations...)

Peter


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: macrodef - do attributes as properties or substitutions

[Stefan Bodewig]

On Fri, 14 Nov 2003, Jan Materne <[EMAIL PROTECTED]> wrote:

> 
> 
> 
> 
> 

I don't think we should need any special cludges just to support this
usecase. 8-)

Give two a completely bogus, impossible to be used in any real world
usage value and check for that.  Should be easier than comparing it to
a literal ${one} or @one or whathever.






Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: macrodef - do attributes as properties or substitutions

[Stefan Bodewig]

On Fri, 14 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> On Friday 14 November 2003 14:07, Stefan Bodewig wrote:
>> On Fri, 14 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:

>> > I do not like using a different notation for attributes.
>>
>> unless they are a different thing than properties, if I understand
>> you correctly.
> Not quite, I mean that if they are differnet from properties, a
> different notation should be used, but I do not like using a
> different notation in principle.

Message understaood, thanks.

> An example:
> 
>   
>
>
>
>
>
>   
> 
>   
> 
>   inmacro is '${inmacro}'
> 
>   
> 
> This shows:
> 
> s:
> inmacro is 'Set in macro'
> 
> It would be very difficult to stop this.

So we must ask outselves whether this is good or bad for us.

If the property inmacro has been defined before the macro invocation,
the task inside the macro will be a noop - the user gets the expected
behavior.

If it has not been set, well, this might come unexpected.

But there will never be any double expansion, right?  I mean, 

  inmacro is '$${inmacro}'

would always result in 

> s:
> inmacro is '${inmacro}'

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: macrodef - do attributes as properties or substitutions

[Jan . Materne]

> > And the question was: how can I access the attribute-value?
> 
> @attribute or $(attribute) or - as long as we use a different notation
> we don't have to fear that we'd accidently clash with properties or
> scripting language constructs.

ok


> > If you write inside a target that would be value =
> > project.getProperty(name); But not here.
> 
> Neither is it in  for example.  If we say that the
> attribute doesn't turn into a property - and don't make it look like
> one - people won't expect they could get at it via
> project.getProperty.

agree


> > But the textual expansion has another disadvantage: 
> > if (parameter == "${name}") set-default-for-parameter;
> > You can´t do that ...
> 
> I'm afraid you've lost me.  

maybe - I haven´t followed thread not very intensive at the beginning ...


> What is the issue you are having here?







Because the expansion isn´t done on that step, two is still set to "${one}".
So I had to check that inside my 

Re: macrodef - do attributes as properties or substitutions

[peter reilly]

On Friday 14 November 2003 14:07, Stefan Bodewig wrote:
> On Fri, 14 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> >  expands the properties at the point of use, not
> > at the point of definition.

> Better note that somewhere prominently.
Ok.

> > On Friday 14 November 2003 10:53, Stefan Bodewig wrote:
> >> Peter, Jan, now that we've seen Jose Alberto's use case - what can
> >> macrodef do when we use (local) properties that can't be done with
> >> textual substitutions?
> >
> > I do not like using a different notation for attributes.
>
> unless they are a different thing than properties, if I understand you
> correctly.
Not quite, I mean that if they are differnet from properties, a different
notation should be used, but I do not like using a different notation
in principle.

> > Other than that, there is not much differnce.  Retaining the ${}
> > format (implying using local properties) would be a benefit, in that
> > porting of antcall's would be easier.
>
> OK.
>
> > If attributes are local properties, there is an issue with shadowing
> > of user properties.
>
> Actually, shadowing any properties, but that's an issue of  in
> general.
>
> >> The only expression evaluation we have in Ant is property expansion
> >> and that would have been performed before the value of the
> >> attribute gets used - and exactly once - no matter how we implement
> >> it, wouldn't it?
> >
> > Not quite, the expansion gets performed just before a task is run,
> > and with macrodef and presetdef, the UE's are stored and (for
> > macrodef's case) copied. If the expansion is done by
> > macrodef/presetdef, it is difficult to stop the expansion being done
> > again later.
>
> At what stage?  I mean, is the a way that
>
> 
> 
>
> was defined and a text of ${foo} somewhere inside a macro (pr
> presetdefed task) would end up being resolved to baz?  I.e. is it
> possible that the same string undergoes macro expansion more than
> once?

An example:

  
   
   
   
   
   
  

  

  inmacro is '${inmacro}'

  

This shows:

s:
inmacro is 'Set in macro'

It would be very difficult to stop this.

Peter

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: macrodef - do attributes as properties or substitutions

[Stefan Bodewig]

On Fri, 14 Nov 2003, Jan Materne <[EMAIL PROTECTED]> wrote:

> And the question was: how can I access the attribute-value?

@attribute or $(attribute) or - as long as we use a different notation
we don't have to fear that we'd accidently clash with properties or
scripting language constructs.

> If you write inside a target that would be value =
> project.getProperty(name); But not here.

Neither is it in  for example.  If we say that the
attribute doesn't turn into a property - and don't make it look like
one - people won't expect they could get at it via
project.getProperty.

> But the textual expansion has another disadvantage: 
> if (parameter == "${name}") set-default-for-parameter;
> You can´t do that ...

I'm afraid you've lost me.  What is the issue you are having here?

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: macrodef - do attributes as properties or substitutions

[Stefan Bodewig]

On Fri, 14 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:

>  expands the properties at the point of use, not
> at the point of definition.

Better note that somewhere prominently.

> On Friday 14 November 2003 10:53, Stefan Bodewig wrote:

>> Peter, Jan, now that we've seen Jose Alberto's use case - what can
>> macrodef do when we use (local) properties that can't be done with
>> textual substitutions?

> I do not like using a different notation for attributes.

unless they are a different thing than properties, if I understand you
correctly.

> Other than that, there is not much differnce.  Retaining the ${}
> format (implying using local properties) would be a benefit, in that
> porting of antcall's would be easier.

OK.

> If attributes are local properties, there is an issue with shadowing
> of user properties.

Actually, shadowing any properties, but that's an issue of  in
general.

>> The only expression evaluation we have in Ant is property expansion
>> and that would have been performed before the value of the
>> attribute gets used - and exactly once - no matter how we implement
>> it, wouldn't it?
> 
> Not quite, the expansion gets performed just before a task is run,
> and with macrodef and presetdef, the UE's are stored and (for
> macrodef's case) copied. If the expansion is done by
> macrodef/presetdef, it is difficult to stop the expansion being done
> again later.

At what stage?  I mean, is the a way that




was defined and a text of ${foo} somewhere inside a macro (pr
presetdefed task) would end up being resolved to baz?  I.e. is it
possible that the same string undergoes macro expansion more than
once?

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: macrodef - do attributes as properties or substitutions

[Jan . Materne]

I came from the users point of view. More exactly while writing access code
inside a script task.
  
  
  
  
  HERE PLAYS THE MUSIC :-)
  
  
  

And the question was: how can I access the attribute-value? If you write
inside a target that would be
value = project.getProperty(name);
But not here. So development / copying the code from somewhere else /
refactor that code out would be
more diffult.

Difficult but not impossible:
value = "${value}";
would do that (or the other bracket type).


But the textual expansion has another disadvantage:
if (parameter == "${name}") set-default-for-parameter;
You can´t do that ... (mmh maybe nevertheless, not enought thought about
that).
So the workaround would be splitting the string "${name}" to "${na"+"me}".


All can be done. But not in a nice and uniform way.
That´s why I prefer local properties.



Jan

RE: macrodef - do attributes as properties or substitutions

[Jose Alberto Fernandez]

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
> 
> On Wed, 12 Nov 2003, Jose Alberto Fernandez 
> <[EMAIL PROTECTED]> wrote:
> 
> > From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> >
> >> In which situation would " modify properties" have
> >> negative effects on what you are planing to do with 
> >> ?  Do you have an enlightening example?
> 
> [attribute is called debug and would shadow a debug property]
> 
> > 
> > >deprecation="${deprecation}" debug="${debug}"/> 
> > 
> 
> I'd expect that the properties have been expanded at the 
> point of  already so there shouldn't be any shadow 
> affecting that definition.
> 

I knew something like this will be in the answer ;-/
But never mind, my only point here is that the user of 
will not see the connection between the attribute and
the behavior of the task. You cound achive the same example
by having:


  
  

 
   
  


So here the properties should be expanded at execution time.
And my comments are the same. They also apply to java tasks
that use properties internally.

None of our container tasks have such behavior. For example
when I write:

   
 ${failonany}
   

there is no expectation that a property called "failonany" will show up
just because I use an attribute of that name. But if parallel was
implemented using a macro, then you get this behavior.
So now, when you use some code from some antlib somewhere, or you import
some build fragment. Now you need to be aware of whether the task
you want to use was an actual java task (that does not messup your
properties) or is some macro-defined task that will mess up your
properties with the names of all the attributes that you pass and
the names of any other attributes of any other macros that that macro
calls before it calls your elements.

Who will understand what is going on on a large project?

It will be just a mess with no benefit what so ever.

Is my hyperbole compelling enough? :-)

Jose Alberto
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: macrodef - do attributes as properties or substitutions

[peter reilly]

On Friday 14 November 2003 10:53, Stefan Bodewig wrote:
>
> > 
> > >deprecation="${deprecation}" debug="${debug}"/>
> > 
>
> I'd expect that the properties have been expanded at the point of
>  already so there shouldn't be any shadow affecting that
> definition.

 expands the properties at the point of use, not
at the point of definition.

>
> > No here the intention of the code writer was to control javac using
> > the debug property. But just because I decided to write myMacro with
> > an attribute called debug, I am changing the behavior of
> > my.java. (if we use locals)
>
> Only if the expansion of properties in presetdef is performed in the
> scope of the macro invocation and not at definition time.  But we
> could simple use your example with
>
>
>  
>${debug}
>  
>
>
> and ask ourselves what the user wanted to say here.  I agree that we
> remove the ambiguity when attributes are not properties.
>
> > But wait, what if I actually wanted to change the property?
> > Well, in that case you can introduce the  yourself
> > as part of the code of the macro:
>
> I knew you'd say that (and I even came to this conclusion all by
> myself already ;-).
>
> Peter, Jan, now that we've seen Jose Alberto's use case - what can
> macrodef do when we use (local) properties that can't be done with
> textual substitutions?  I may be willing to swallow  in 1.6
> even if macrodef attributes don't use it.

I do not like using a different notation for attributes. After
programming in perl for many years, (many years ago), I came to
hate the different notations for arrays, scalars, maps, and ?Files?.
However, if attributes are done by textual notation, they should have
a different notation.


  
$(debug) is not ${debug}
  


Other than that, there is not much differnce. Retaining the ${} format
(implying using local properties) would be a benefit, in that porting
of antcall's would be easier.

If attributes are local properties, there is an issue with shadowing
of user properties. In the above case, it is common for people to
do ant -Ddebug=no ...


>
> The main problems other languages have with macros as textual
> replacements (i.e. Lisp's defmacro or C's #define) is that the
> expression you pass in may be evaluated more than one.
> I.e. #define square(x) x * x and used as square(i++) may lead to
> unexpected results.
>
> The only expression evaluation we have in Ant is property expansion
> and that would have been performed before the value of the attribute
> gets used - and exactly once - no matter how we implement it, wouldn't
> it?

Not quite, the expansion gets performed just before a task is run, and
with macrodef and presetdef, the UE's are stored and (for macrodef's case)
copied. If the expansion is done by macrodef/presetdef, it is difficult to
stop the expansion being done again later. It had a version of
RuntimeConfigureable with kept track of the expansion, but this does not
work for expansion done by tasks for addText().

Peter

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: macrodef - do attributes as properties or substitutions

[Stefan Bodewig]

On Wed, 12 Nov 2003, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:

[scriptdef and beanshell]

> Line numbers never match with that of the srcfiles.  But back to the
> topic.

Looks as if Peter sees the same - a BSF problem of not passing the
correct line number in?

> I want macrodef for when all I need to do is to put toguether
> a group of calls to other tasks in a sequence, which could be
> quite complex, but it does not require any additional computation
> from my part:

And I don't want to take that away - neither from you nor anybody else
8-)

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
>
>> In which situation would " modify properties" have 
>> negative effects on what you are planing to do with 
>> ?  Do you have an enlightening example?

[attribute is called debug and would shadow a debug property]

> 
>deprecation="${deprecation}" debug="${debug}"/>
> 

I'd expect that the properties have been expanded at the point of
 already so there shouldn't be any shadow affecting that
definition.

> No here the intention of the code writer was to control javac using
> the debug property. But just because I decided to write myMacro with
> an attribute called debug, I am changing the behavior of
> my.java. (if we use locals)

Only if the expansion of properties in presetdef is performed in the
scope of the macro invocation and not at definition time.  But we
could simple use your example with

   
 
   ${debug}
 
   

and ask ourselves what the user wanted to say here.  I agree that we
remove the ambiguity when attributes are not properties.

> But wait, what if I actually wanted to change the property?
> Well, in that case you can introduce the  yourself
> as part of the code of the macro:

I knew you'd say that (and I even came to this conclusion all by
myself already ;-).

Peter, Jan, now that we've seen Jose Alberto's use case - what can
macrodef do when we use (local) properties that can't be done with
textual substitutions?  I may be willing to swallow  in 1.6
even if macrodef attributes don't use it.

The main problems other languages have with macros as textual
replacements (i.e. Lisp's defmacro or C's #define) is that the
expression you pass in may be evaluated more than one.  
I.e. #define square(x) x * x and used as square(i++) may lead to
unexpected results.

The only expression evaluation we have in Ant is property expansion
and that would have been performed before the value of the attribute
gets used - and exactly once - no matter how we implement it, wouldn't
it?

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: macrodef - do attributes as properties or substitutions

[Steve Cohen]

>> "I want macrodef for when all I need to do is to put toguether
a group of calls to other tasks in a sequence, which could be
quite complex, but it does not require any additional computation
from my part"

Hear, hear! 

Used in this way, you can use ant, cutting out expensive  calls and 
most 's.  I myself have never written a  and don't want to 
start unless I really have to do something specialized. 's and what 
they do are a mystery to readers of a build script and IMHO should not be used 
just to glue targets together in some particular way unless there is a very 
good reason for it.

That's what I want from .

-Original Message-
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 12, 2003 12:37 PM
To: Ant Developers List
Subject: RE: macrodef - do attributes as properties or substitutions


> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> On Tue, 11 Nov 2003, Jose Alberto Fernandez 
> 
> > To me macrodefs are for writing all those tasks that I am
> too lazy, or
> > they are too simple for me to need to go and write and
> maintain some
> > Java code.
> 
> I'm not sure that this is the intention of  - maybe
> you would rather use  with beanshell as your 
> scripting language then?
> 

I do use it extensively. And believe me, every time we have a 
syntax or logical error in the code it takes 1o times longer
to find it. Line numbers never match with that of the srcfiles.
But back to the topic.

I want macrodef for when all I need to do is to put toguether
a group of calls to other tasks in a sequence, which could be
quite complex, but it does not require any additional computation
from my part:


  
  










  
  



  


  
  



  


  
  



  


  
  



  

  


Today, I need to do this by calling  because I need to pass diferent
parameters in different places. It will look much better that instead of:






I can just say:



You can see that using scriptdef to do this job is absolute madness. Since all 
you need is
to put toguether some tasks.

> > Substitution is the least interfearing behavior.
> 
> I hear you and to a certain degree I agree with you.  
> Actually I haven't really made up my mind myself yet - no 
> vote from me so far.
> 
> > But if  modify properties, then there is no way 
> for me to 
> > stop them for happening.
> 
> In which situation would " modify properties" have 
> negative effects on what you are planing to do with 
> ?  Do you have an enlightening example?
> 

  



  


  myMacro: Entering my macro
  
  myMacro: Entering my macro


  

  

  

So here we have this simple macro that adds some debug information.

So I use it like:

   
 
   
 
   

Still, very naïve code. Until you see that the definition of my.java is:


   


No here the intention of the code writer was to control javac using the
debug property. But just because I decided to write myMacro with an
attribute called debug, I am changing the behavior of my.java. (if we use 
locals)

If this one is not convinsing enough, I am sure we can build one based on
this model.

If we were doing replacement, this will not happen. The attribute "debug"
will only affect the  and not the things inside .

But wait, what if I actually wanted to change the property?
Well, in that case you can introduce the  yourself
as part of the code of the macro:


  



  

  
  
myMacro: Entering my macro

myMacro: Entering my macro
  
  

  

  

  

Here, I guess I need diferent syntax so I can talk about the attribute
and the property at the same time.

So as I said, textual replacement is not only the one least surprising
but it is also the most flexible. You cannot do it the other way around.

Jose Alberto

> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: macrodef - do attributes as properties or substitutions

[Jose Alberto Fernandez]

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
> On Tue, 11 Nov 2003, Jose Alberto Fernandez 
> 
> > To me macrodefs are for writing all those tasks that I am 
> too lazy, or 
> > they are too simple for me to need to go and write and 
> maintain some 
> > Java code.
> 
> I'm not sure that this is the intention of  - maybe 
> you would rather use  with beanshell as your 
> scripting language then?
> 

I do use it extensively. And believe me, every time we have a 
syntax or logical error in the code it takes 1o times longer
to find it. Line numbers never match with that of the srcfiles.
But back to the topic.

I want macrodef for when all I need to do is to put toguether
a group of calls to other tasks in a sequence, which could be
quite complex, but it does not require any additional computation
from my part:


  
  










  
  



  


  
  



  


  
  



  


  
  



  

  


Today, I need to do this by calling  because I need to pass diferent
parameters in different places. It will look much better that instead of:






I can just say:



You can see that using scriptdef to do this job is absolute madness. Since all 
you need is
to put toguether some tasks.

> > Substitution is the least interfearing behavior.
> 
> I hear you and to a certain degree I agree with you.  
> Actually I haven't really made up my mind myself yet - no 
> vote from me so far.
> 
> > But if  modify properties, then there is no way 
> for me to 
> > stop them for happening.
> 
> In which situation would " modify properties" have 
> negative effects on what you are planing to do with 
> ?  Do you have an enlightening example?
> 

  



  


  myMacro: Entering my macro
  
  myMacro: Entering my macro


  

  

  

So here we have this simple macro that adds some debug information.

So I use it like:

   
 
   
 
   

Still, very naïve code. Until you see that the definition of my.java is:


   


No here the intention of the code writer was to control javac using the
debug property. But just because I decided to write myMacro with an
attribute called debug, I am changing the behavior of my.java. (if we use 
locals)

If this one is not convinsing enough, I am sure we can build one based on
this model.

If we were doing replacement, this will not happen. The attribute "debug"
will only affect the  and not the things inside .

But wait, what if I actually wanted to change the property?
Well, in that case you can introduce the  yourself
as part of the code of the macro:


  



  

  
  
myMacro: Entering my macro

myMacro: Entering my macro
  
  

  

  

  

Here, I guess I need diferent syntax so I can talk about the attribute
and the property at the same time.

So as I said, textual replacement is not only the one least surprising
but it is also the most flexible. You cannot do it the other way around.

Jose Alberto

> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: macrodef - do attributes as properties or substitutions

[peter reilly]

On Tuesday 11 November 2003 19:01, Jose Alberto Fernandez wrote:
> BTW, how this things will affect the other tasks derived from macrodef
> like presetdef?

Although they were introduced at the same time and
in some ways are similar, presetdef is not derived from macrodef.

Note that a recent change to  has made it more
usefull.

Originally if the same attributes where in the preset and then reset in the
script,
the attributes in question would be set twice. This causes some grief.
The implementation now (in cvs and the next 1.6 beta), treats the attributes
as default values which may be overridden when used.

For example:

   


   

now works as expected.

Peter

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: macrodef - do attributes as properties or substitutions

[Stefan Bodewig]

On Tue, 11 Nov 2003, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:

> To me macrodefs are for writing all those tasks that I am too
> lazy, or they are too simple for me to need to go and write and
> maintain some Java code.

I'm not sure that this is the intention of  - maybe you
would rather use  with beanshell as your scripting language
then?

> Substitution is the least interfearing behavior.

I hear you and to a certain degree I agree with you.  Actually I
haven't really made up my mind myself yet - no vote from me so far.

> But if  modify properties, then there is no way for me to
> stop them for happening.

In which situation would " modify properties" have negative
effects on what you are planing to do with ?  Do you have an
enlightening example?

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: macrodef - do attributes as properties or substitutions

[Jose Alberto Fernandez]

> From: Steve Cohen [mailto:[EMAIL PROTECTED] 
> 
> Wouldn't you say, though, Jose, that  does replace 
> those uses of  for which  had too big a 
> footprint for the job?  
> 

Oh, but of course. I do plan to use macrodef to replace things
that I did with  before. But the reason they were done
with  before, is that it was more convinient than writing
the equivalent script or java code; they did not need to evaluate
multiple targets or other complex stuff. 

For things more complex,  is still the way to go. Why?
Because it provides a new execution context, in which I can deside
whether properties are inherited or not, and it provides isolation
so that the parent context is not directly manipulated by the child.

 using  would be a cluge in the middle, half here
half there, which I think is wrong. Either is a macro definition 
(as the term is defined in computer science form the days of assembler)
it should be called something else and have a real execution context.

BTW, how this things will affect the other tasks derived from macrodef
like presetdef?


Jose Alberto

> -Original Message-
> From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, November 11, 2003 11:19 AM
> To: Ant Developers List
> Subject: RE: macrodef - do attributes as properties or substitutions
> 
> 
> I think I need to justify some more what do I think the way I 
> do about macrodef. I know the vote is already going, but I 
> really want for people to understand my position.
> 
> To me macrodefs are for writing all those tasks that I am too 
> lazy, or they are too simple for me to need to go and write 
> and maintain some Java code. It is not to replace  
> but as a side efect, it will replace all those little 
> antcalls we wrote 
> because we didn't want to write java.
> 
> With that in mind, I would want  to resemble a Java 
> task and not to resemble . And if it resemples a 
> java task, then attributes should resemble java variables in my code. 
> That is, its values should not affect the values of 
> properties (which is what  does). If I want a task to 
> affect other tasks then I can always call  or 
>  as part of the macro. But if  modify 
> properties, then there is no way for me to stop them for happening.
> 
> Substitution is the least interfearing behavior.
> 
> So, that is why I think the way I do. Comments? changes of votes? :-)
> 
> Jose Alberto
>  
> > -Original Message-
> > From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> > Sent: 11 November 2003 12:23
> > To: [EMAIL PROTECTED]
> > Subject: [VOTE] macrodef - do attributes as properties or
> > substitutions
> > 
> > 
> > Hi,
> > 
> > I don't think that another discussion thread will lead us anywhere. 
> > Instead of trying to summarize what has been discussed, let 
> me point 
> > to the archives (I hope the list is complete):
> > 
> <http://marc.theaimsgroup.com/?t=10608526902&r=1&w=2>
> <http://marc.theaimsgroup.com/?t=10663364313&r=1&w=2>
> <http://marc.theaimsgroup.com/?t=10667505815&r=1&w=2>
> <http://marc.theaimsgroup.com/?t=10663917564&r=1&w=2>
> <http://marc.theaimsgroup.com/?t=10667294715&r=1&w=2>
> <http://marc.theaimsgroup.com/?t=10672090301&r=1&w=2>
> <http://marc.theaimsgroup.com/?t=10676180933&r=1&w=2>
> 
> I'd like to keep this particular vote focussed on property 
> versus textual substitution.  I am aware that the vote won't 
> be complete after that as we'll still have issues to decide 
> upon (scope+extent or notation, depending on this vote's 
> outcome), but let's get this one here straight first.
> 
> Actually, I'm not 100% sure about the rules we have to apply 
> since we've already shipped betas with the code, so strictly 
> speaking a decision we are considering a code change which 
> would require (lazy) consensus of the committers as opposed 
> to a new idea that would require a majority only.  Let's see 
> where we get from here and whether we'll have to actually 
> decide that at all 8-)
> 
> Stefan
> 
> OK, how do we want to implement  attributes:
> 
> [ ] as textual substitution
> [ ] as "real" Ant properties
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: macrodef - do attributes as properties or substitutions

[Steve Cohen]

Wouldn't you say, though, Jose, that  does replace those uses
of  for which  had too big a footprint for the job?  

-Original Message-
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 11, 2003 11:19 AM
To: Ant Developers List
Subject: RE: macrodef - do attributes as properties or substitutions


I think I need to justify some more what do I think the way I do about
macrodef. I know the vote is already going, but I really want for people
to understand my position.

To me macrodefs are for writing all those tasks that I am too lazy, or
they are too simple for me to need to go and write and maintain some
Java code. It is not to replace  but as a side efect, it will
replace all those little antcalls we wrote 
because we didn't want to write java.

With that in mind, I would want  to resemble a Java task and
not to resemble . And if it resemples a java task, then
attributes should resemble java variables in my code. 
That is, its values should not affect the values of properties (which is
what  does). If I want a task to affect other tasks then I can
always call  or  as part of the macro. But if
 modify properties, then there is no way for me to stop them
for happening.

Substitution is the least interfearing behavior.

So, that is why I think the way I do. Comments? changes of votes? :-)

Jose Alberto
 
> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: 11 November 2003 12:23
> To: [EMAIL PROTECTED]
> Subject: [VOTE] macrodef - do attributes as properties or 
> substitutions
> 
> 
> Hi,
> 
> I don't think that another discussion thread will lead us
> anywhere. Instead of trying to summarize what has been 
> discussed, let me point to the archives (I hope the list is complete):
> 
<http://marc.theaimsgroup.com/?t=10608526902&r=1&w=2>
<http://marc.theaimsgroup.com/?t=10663364313&r=1&w=2>
<http://marc.theaimsgroup.com/?t=10667505815&r=1&w=2>
<http://marc.theaimsgroup.com/?t=10663917564&r=1&w=2>
<http://marc.theaimsgroup.com/?t=10667294715&r=1&w=2>
<http://marc.theaimsgroup.com/?t=10672090301&r=1&w=2>
<http://marc.theaimsgroup.com/?t=10676180933&r=1&w=2>

I'd like to keep this particular vote focussed on property versus
textual substitution.  I am aware that the vote won't be complete after
that as we'll still have issues to decide upon (scope+extent or
notation, depending on this vote's outcome), but let's get this one here
straight first.

Actually, I'm not 100% sure about the rules we have to apply since we've
already shipped betas with the code, so strictly speaking a decision we
are considering a code change which would require (lazy) consensus of
the committers as opposed to a new idea that would require a majority
only.  Let's see where we get from here and whether we'll have to
actually decide that at all 8-)

Stefan

OK, how do we want to implement  attributes:

[ ] as textual substitution
[ ] as "real" Ant properties

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: macrodef - do attributes as properties or substitutions

[Jose Alberto Fernandez]

I think I need to justify some more what do I think the way I do
about macrodef. I know the vote is already going, but I really
want for people to understand my position.

To me macrodefs are for writing all those tasks that I am too
lazy, or they are too simple for me to need to go and write and
maintain some Java code. It is not to replace  but
as a side efect, it will replace all those little antcalls we wrote 
because we didn't want to write java.

With that in mind, I would want  to resemble a Java task
and not to resemble . And if it resemples a java task,
then attributes should resemble java variables in my code. 
That is, its values should not affect the values of properties
(which is what  does). If I want a task to affect other tasks
then I can always call  or  as part of the macro.
But if  modify properties, then there is no way for me
to stop them for happening.

Substitution is the least interfearing behavior.

So, that is why I think the way I do. Comments? changes of votes? :-)

Jose Alberto
 
> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
> Sent: 11 November 2003 12:23
> To: [EMAIL PROTECTED]
> Subject: [VOTE] macrodef - do attributes as properties or 
> substitutions
> 
> 
> Hi,
> 
> I don't think that another discussion thread will lead us 
> anywhere. Instead of trying to summarize what has been 
> discussed, let me point to the archives (I hope the list is complete):
> 








I'd like to keep this particular vote focussed on property versus
textual substitution.  I am aware that the vote won't be complete after
that as we'll still have issues to decide upon (scope+extent or
notation, depending on this vote's outcome), but let's get this one here
straight first.

Actually, I'm not 100% sure about the rules we have to apply since we've
already shipped betas with the code, so strictly speaking a decision we
are considering a code change which would require (lazy) consensus of
the committers as opposed to a new idea that would require a majority
only.  Let's see where we get from here and whether we'll have to
actually decide that at all 8-)

Stefan

OK, how do we want to implement  attributes:

[ ] as textual substitution
[ ] as "real" Ant properties

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]