RE: [VOTE] macrodef - do attributes as properties or substitutions

[Matt Benson]

> Actually if we go for reading value, the advantage
> of @{x} notation is
> that sounds like "AT(tribute) x" :-)

Yeah, add another non-committer vote for @{x}...


__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

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

RE: [VOTE] macrodef - do attributes as properties or substitutions

[Jose Alberto Fernandez]

> From: Dominique Devienne [mailto:[EMAIL PROTECTED] 
> 
> 
> Unlike Jose Alberto, I think it's a 'good' thing than 
> referencing an declared attribute of a  in its 
> body/impl resembles the XSLT referencing of a attribute of 
> the current XML element!
> 
> The similarities are striking, and the syntax is well known 
> and clearly documented. The  attribute *will* be an 
> XML element attribute when it's used actually!!!
> 

Well just remember that in XSLT we are talking about XPATH.
The actual parameters here are "@x" (an attribute) or "$x"
(a variable) or "x" an element. The "{}" is just syntax sugar
so you can write expressions easily inside XSLT attribute values.

In XSLT you can write:

which results in the concatenation of the three values.

But you can also write that more verbose:

   

  

   

XSLT has a very specific syntax for variable/attribute names.

> The point is not to resemble the existing notation for 
> dereferencing Ant properties, since that's what it's supposed 
> to be distinct from, which is why @{x} feels wrong to me (and 
> looks ugly IMHO ;-).
> 
> The point is to use a widely used notation for a widely 
> similar purpose, i.e. the XSLT notation, which as I noted 
> above is so similar to the semantic of what's being done.

Your proposal selection is not XPATH nor the XSLT expression language,
yes it has some simillarities, but on the other hand that may add to
confusion.

Jose Alberto
PS: my current choice is "@{x}" before was "$(x)", hum
maybe should pick "@(x)" humm, oh well, somebody, just pick
something!!!

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

RE: [VOTE] macrodef - do attributes as properties or substitutions

[Jose Alberto Fernandez]

> From: Gus Heck [mailto:[EMAIL PROTECTED] 
> 
> My (non-committer) oppion coincides with Stefan here,  with a slight 
> preference for
> 
> @{x}
> 
> because it looks like "put the substitution AT this location" when I 
> read it to myself.
> 

Actually if we go for reading value, the advantage of @{x} notation is
that sounds like "AT(tribute) x" :-)

I think I can live with that.

Jose Alberto


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

Re: [VOTE] macrodef - do attributes as properties or substitutions

[Gus Heck]

My (non-committer) oppion coincides with Stefan here,  with a slight 
preference for

@{x}
because it looks like "put the substitution AT this location" when I 
read it to myself.

However I can understand that $ escaping is already done and well tested 
so reusing that code has value. $(x) is good enough for me if that is a 
priorety (you will note I am not offering to code @{x} :) ). 

(or we could make it (:x:) so that mozilla can turn them all into 
smilies when we paste it to the list :) )

-Gus
Stefan Bodewig wrote:
On Mon, 17 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:
 

OK, how do we want to implement  attributes:
 current
[ ] as textual substitution~ 4
[ ] as "real" Ant properties   ~ 2
undecided   ~ 1
   

only counting the "binding" votes would result in 1/2/1, so neither
choice has received enough binding votes by now.  Dominique, Jose
Alberto and Steve know that I'm not ignoring their votes, but
technically they are non-binding.
 

If macrodef attribute are to be implements as substitutions, what
should be the notation? (where x is the attribute name)
[ ] as ${x} (look like ant properties)
   

-1, too confusing.
 

[ ] as @x
   

-1 doesn't work if you want to concatenate an expanded attribute and
some other text, i.e.


is @foobarbaz the expansion of foo plus the literal text barbaz or is
it the attribute foobar plus the literal text baz - or something
completely different?
 

[ ] as ${attribute:x}
   

-1 - still looks too much like a property and collides with existing
properties that's name starts with "attribute:" (unlikely but
possible).
 

[ ] as $(x) 
[ ] as @{x}
   

either one works for me - as well as [EMAIL PROTECTED]
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: [VOTE] macrodef - do attributes as properties or substitutions

[Steve Cohen]

What about {$x}? Or is it too close to a typo for a regular property?

way too confusing, IMHO.  And departs significant from our "pattern"
which seems to be 
identifier type marker, open curly brace, identifier, close curly brace

The more I look at this, the clearer my clear choice becomes for @{x}.
It maintains the ant "pattern" of identifier naming while being quite
significantly different in an important way so that visual confusion
will be unlikely, even when the script writer is tired :-)


-Original Message-
From: Shatzer, Larry [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 18, 2003 10:09 AM
To: 'Ant Developers List'
Subject: RE: [VOTE] macrodef - do attributes as properties or
substitutions


> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 18, 2003 2:08 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [VOTE] macrodef - do attributes as properties or 
> substitutions
> 
> >  [ ] as $(x)
> >  [ ] as @{x}
> 
> either one works for me - as well as [EMAIL PROTECTED]
> 

What about {$x}? Or is it too close to a typo for a regular property?

-- Larry

-
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: [VOTE] macrodef - do attributes as properties or substitutions

[Stefan Bodewig]

On Mon, 17 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:

> OK, how do we want to implement  attributes:
>   current
>  [ ] as textual substitution~ 4
>  [ ] as "real" Ant properties   ~ 2
> 
> undecided   ~ 1

only counting the "binding" votes would result in 1/2/1, so neither
choice has received enough binding votes by now.  Dominique, Jose
Alberto and Steve know that I'm not ignoring their votes, but
technically they are non-binding.

> If macrodef attribute are to be implements as substitutions, what
> should be the notation? (where x is the attribute name)
> 
>  [ ] as ${x} (look like ant properties)

-1, too confusing.

>  [ ] as @x

-1 doesn't work if you want to concatenate an expanded attribute and
some other text, i.e.




is @foobarbaz the expansion of foo plus the literal text barbaz or is
it the attribute foobar plus the literal text baz - or something
completely different?

>  [ ] as ${attribute:x}

-1 - still looks too much like a property and collides with existing
properties that's name starts with "attribute:" (unlikely but
possible).

>  [ ] as $(x) 
>  [ ] as @{x}

either one works for me - as well as [EMAIL PROTECTED]

Stefan

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

RE: [VOTE] macrodef - do attributes as properties or substitutions

[Jose Alberto Fernandez]

No matter what syntax we decide to use we need
to provide an escape sequence for it.
Even if we know of no conflict today, tomorrow one 
may show up. Hence we should face the music head on.

I think matching other languages (like XSLT or something)
is really wrong.

My only reason for suggesting a syntax starting with
$ is that we already have rules for escaping them,
if we use other very different syntax (like [EMAIL PROTECTED] ) 
we need to invent some new syntax for escaping it.

This is why I want something simple and close to what ANT already
has, so that we can move on quicly on this issue that has been
dragging us on for way too long.

Jose Alberto

> -Original Message-
> From: Steve Cohen [mailto:[EMAIL PROTECTED] 
> Sent: 17 November 2003 18:50
> To: Ant Developers List
> Subject: RE: [VOTE] macrodef - do attributes as properties or 
> substitutions
> 
> 
> Another non committer here.
> I don't like $(x) because it looks too much like ${x}, 
> although I suppose I could get used to that.  Therfore, I am 
> drawn to @{x}.  ${attribute:x} is possible but way too much 
> typing for my taste. Abbreviated to ${att:x} or ${attrib:x} 
> my negativity level goes down accordingly.
> 
> Before "voting", though, could someone list all the 
> conflicting usages with other systems that ant must interface with.
> 
> -Original Message-
> From: peter reilly [mailto:[EMAIL PROTECTED] 
> Sent: Monday, November 17, 2003 12:10 PM
> To: Ant Developers List
> Subject: Re: [VOTE] macrodef - do attributes as properties or 
> substitutions
> 
> 
> OK, how do we want to implement  attributes:
>   current
>  [ ] as textual substitution~ 4
>  [ ] as "real" Ant properties   ~ 2
> 
> undecided   ~ 1
> 
> If macrodef attribute are to be implements as substitutions, 
> what should be the notation? (where x is the attribute name)
> 
>  [ ] as ${x} (look like ant properties)
>  [ ] as $(x) 
>  [ ] as @x
>  [ ] as ${attribute:x}
>  [ ] as @{x}
>  [ ] some thing else
> 
> 
> 
> -
> 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: [VOTE] macrodef - do attributes as properties or substitutions

[Steve Cohen]

Another non committer here.
I don't like $(x) because it looks too much like ${x}, although I
suppose I could get used to that.  Therfore, I am drawn to
@{x}.  ${attribute:x} is possible but way too much typing for my taste.
Abbreviated to ${att:x} or ${attrib:x} my negativity level goes down
accordingly.

Before "voting", though, could someone list all the conflicting usages
with other systems that ant must interface with.

-Original Message-
From: peter reilly [mailto:[EMAIL PROTECTED] 
Sent: Monday, November 17, 2003 12:10 PM
To: Ant Developers List
Subject: Re: [VOTE] macrodef - do attributes as properties or
substitutions


OK, how do we want to implement  attributes:
  current
 [ ] as textual substitution~ 4
 [ ] as "real" Ant properties   ~ 2

undecided   ~ 1

If macrodef attribute are to be implements as substitutions, what should
be the notation? (where x is the attribute name)

 [ ] as ${x} (look like ant properties)
 [ ] as $(x) 
 [ ] as @x
 [ ] as ${attribute:x}
 [ ] as @{x}
 [ ] some thing else



-
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: [VOTE] macrodef - do attributes as properties or substitutions

[Jose Alberto Fernandez]

Yes I am not a committer, but anyway ;-)

 [X] as $(x)  +1 
 [X] as ${attribute:x} +0.5

Cannot decide between the two. But by using '$' I think
we can resolve any issues with escaping using the rules we already
have for properties. The others would require a different convention.

Jose Alberto

> -Original Message-
> From: peter reilly [mailto:[EMAIL PROTECTED] 
> Sent: 17 November 2003 18:10
> To: Ant Developers List
> Subject: Re: [VOTE] macrodef - do attributes as properties or 
> substitutions
> 
> 
> OK, how do we want to implement  attributes:
>   current
>  [ ] as textual substitution~ 4
>  [ ] as "real" Ant properties   ~ 2
> 
> undecided   ~ 1
> 
> If macrodef attribute are to be implements as substitutions, 
> what should be the notation? (where x is the attribute name)
> 
>  [ ] as ${x} (look like ant properties)
>  [ ] as $(x) 
>  [ ] as @x
>  [ ] as ${attribute:x}
>  [ ] as @{x}
>  [ ] some thing else
> 
> 
> 
> -
> 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: [VOTE] macrodef - do attributes as properties or substitutions

[peter reilly]

OK, how do we want to implement  attributes:
  current
 [ ] as textual substitution~ 4
 [ ] as "real" Ant properties   ~ 2

undecided   ~ 1

If macrodef attribute are to be implements as substitutions, what
should be the notation? (where x is the attribute name)

 [ ] as ${x} (look like ant properties)
 [ ] as $(x) 
 [ ] as @x
 [ ] as ${attribute:x}
 [ ] as @{x}
 [ ] some thing else



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

Re: [VOTE] macrodef - do attributes as properties or substitutions

[Stefan Bodewig]

> OK, how do we want to implement  attributes:
> 
> [X] as textual substitution
> [ ] as "real" Ant properties

Stefan

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

AW: [VOTE] macrodef - do attributes as properties or substitutions

[Antoine Levy-Lambert]

Sorry,
I would like to cancel my vote.
I am not too sure any more what is the right decision.

Cheers,

Antoine

-Ursprungliche Nachricht-
Von: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 11. November 2003 14:49
An: Ant Developers List
Betreff: AW: [VOTE] macrodef - do attributes as properties or
substitutions


On Tuesday 11 November 2003 12:22, Stefan Bodewig wrote:
> Stefan
>
> OK, how do we want to implement  attributes:
>
> [ ] as textual substitution
> [X] as "real" Ant properties

Antoine





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

RE: [VOTE] macrodef - do attributes as properties or substitutions

[Steve Cohen]

I don't have a vote but if I did, I'd be
 [X] as textual substitution
 [ ] as "real" Ant properties 

-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 11, 2003 10:14 AM
To: 'Ant Developers List'
Subject: RE: [VOTE] macrodef - do attributes as properties or
substitutions


> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> OK, how do we want to implement  attributes:
> 
> [X] 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]

RE: [VOTE] macrodef - do attributes as properties or substitutions

[Jose Alberto Fernandez]

OK, how do we want to implement  attributes:

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

I know I am not a committer, but ...

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

AW: [VOTE] macrodef - do attributes as properties or substitutions

[Antoine Levy-Lambert]

On Tuesday 11 November 2003 12:22, Stefan Bodewig wrote:
> Stefan
>
> OK, how do we want to implement  attributes:
>
> [ ] as textual substitution
> [X] as "real" Ant properties

Antoine



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

Re: [VOTE] macrodef - do attributes as properties or substitutions

[peter reilly]

On Tuesday 11 November 2003 12:22, Stefan Bodewig wrote:
> Stefan
>
> OK, how do we want to implement  attributes:
>
> [ ] as textual substitution
> [X] as "real" Ant properties

Peter

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

[VOTE] macrodef - do attributes as properties or substitutions

[Stefan Bodewig]

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]