RE: [VOTE] macrodef - do attributes as properties or substitution s
> Everyone is entitled to your opinion, and everyone else is > entitled to > their own, wrong opinion. Right, Dominique? ;^) > > Just to be contrarian (but not really), the "[EMAIL PROTECTED]" notation > looks weird to > me! "@{x}" is familiar enough, although I can't say why at > the moment -- > oh, yeah, doesn't Perl have a similar construct? Perl: $name - scalar: a 'normal' variable (numbers/strings depends on context) @name - array : usual array of scalars; $name[0] %name - hash : key(string)-value(scalar) pairs; $name{key} Maybe Perl 6 introduces some other ... who knows Jan > > I've watched this discussion all the way through, and I can see the > benefits of both approaches. FWIW, seems to me that a > run-time definition > of a property within the macro ( rears its ugly(?!) > head again) is > desirable. Although a straight textual substitution will be easily > understood by folks familiar with the C/C++ pre-processor. > > I feel strongly both ways! :^/ > > Ken > > At 10:11 2003-11-19, you wrote: > > > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] > > > > 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. > > > >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!!! > > > >[EMAIL PROTECTED] feels very natural, and avoids any confusion with ${x}. > >It can be easily escaped using the double symbol people like, > >so that {@@x} passes thru as the [EMAIL PROTECTED] literal. (After all, I > >don't > >think it's valid to have an XML attribute starting with an @, so > >it's free of conflict too.) > > > >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. > > > >I'm not a committer and all, but to me [EMAIL PROTECTED] is the clear choice > >for > > attribute dereferencing. I'm sure others will disagree ;-) > >But no one can escape getting my opinion on the matter ;- --DD > > > >- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > = > J. Kenneth Gentle (Ken)| Phone: (610) 255-0361 > Gentle Software, LLC | Email: [EMAIL PROTECTED] > = > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
RE: [VOTE] macrodef - do attributes as properties or substitution s
LOL! This got the office rolling on the floor. > -Original Message- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 19, 2003 11:40 AM > To: [EMAIL PROTECTED] > Subject: Re: [VOTE] macrodef - do attributes as properties or > substitution s > > > On Wed, 19 Nov 2003, Ken Gentle <[EMAIL PROTECTED]> wrote: > > > "@{x}" is familiar enough, although I can't say why at the moment > > It's a grid bug (or a xorn, dunno without colors) between a moat and a > fountain with an adventurer/human/elf next to it. > > 8-) > > 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 substitution s
On Wed, 19 Nov 2003, Ken Gentle <[EMAIL PROTECTED]> wrote: > "@{x}" is familiar enough, although I can't say why at the moment It's a grid bug (or a xorn, dunno without colors) between a moat and a fountain with an adventurer/human/elf next to it. 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] macrodef - do attributes as properties or substitution s
On Wednesday 19 November 2003 16:13, Ken Gentle wrote: > > Just to be contrarian (but not really), the "[EMAIL PROTECTED]" notation > looks weird to > me! "@{x}" is familiar enough, although I can't say why at the moment -- > oh, yeah, doesn't Perl have a similar construct? If not today then some day. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] macrodef - do attributes as properties or substitution s
Everyone is entitled to your opinion, and everyone else is entitled to their own, wrong opinion. Right, Dominique? ;^) Just to be contrarian (but not really), the "[EMAIL PROTECTED]" notation looks weird to me! "@{x}" is familiar enough, although I can't say why at the moment -- oh, yeah, doesn't Perl have a similar construct? I've watched this discussion all the way through, and I can see the benefits of both approaches. FWIW, seems to me that a run-time definition of a property within the macro ( rears its ugly(?!) head again) is desirable. Although a straight textual substitution will be easily understood by folks familiar with the C/C++ pre-processor. I feel strongly both ways! :^/ Ken At 10:11 2003-11-19, you wrote: > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] > > 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. 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!!! [EMAIL PROTECTED] feels very natural, and avoids any confusion with ${x}. It can be easily escaped using the double symbol people like, so that {@@x} passes thru as the [EMAIL PROTECTED] literal. (After all, I don't think it's valid to have an XML attribute starting with an @, so it's free of conflict too.) 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. I'm not a committer and all, but to me [EMAIL PROTECTED] is the clear choice for attribute dereferencing. I'm sure others will disagree ;-) But no one can escape getting my opinion on the matter ;- --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] = J. Kenneth Gentle (Ken)| Phone: (610) 255-0361 Gentle Software, LLC | Email: [EMAIL PROTECTED] = - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] macrodef - do attributes as properties or substitution s
> From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] > > 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. 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!!! [EMAIL PROTECTED] feels very natural, and avoids any confusion with ${x}. It can be easily escaped using the double symbol people like, so that {@@x} passes thru as the [EMAIL PROTECTED] literal. (After all, I don't think it's valid to have an XML attribute starting with an @, so it's free of conflict too.) 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. I'm not a committer and all, but to me [EMAIL PROTECTED] is the clear choice for attribute dereferencing. I'm sure others will disagree ;-) But no one can escape getting my opinion on the matter ;- --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] macrodef - do attributes as properties or substitution s
> -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]
RE: [VOTE] macrodef - do attributes as properties or substitution s
> >>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) confusion with 'real' > > properties > > [ ] as $(x) to close to A > > [ ] as @x I miss the brackets > > [ ] as ${attribute:x} too long > > [X] as @{x} ok, close to > A but seeable > > different > > [ ] some thing else nothing in my > mind to that > > Has someone ruled out $${x}? Or does that conflict with > using $$ as some kind of escape sequence for $? That´s a part of "some thing else" :-) But you will confound that with escaping sequence of properties. Jan
Re: [VOTE] macrodef - do attributes as properties or substitution s
[EMAIL PROTECTED] wrote: 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) confusion with 'real' properties [ ] as $(x) to close to A [ ] as @x I miss the brackets [ ] as ${attribute:x} too long [X] as @{x} ok, close to A but seeable different [ ] some thing else nothing in my mind to that Has someone ruled out $${x}? Or does that conflict with using $$ as some kind of escape sequence for $? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] macrodef - do attributes as properties or substitution s
> 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) confusion with 'real' properties [ ] as $(x) to close to A [ ] as @x I miss the brackets [ ] as ${attribute:x} too long [X] as @{x} ok, close to A but seeable different [ ] some thing else nothing in my mind to that - a construct according to seems to be too long - other XSLT constructs: $attribname, @attribname: I miss the brackets ... - escape sequence for E could be: @@{x}; doubling the special character is widely used Jan
RE: [VOTE] macrodef - do attributes as properties or substitution s
I know that Canoo WebTest uses %{x} as its own variable substitution. > -Original Message- > From: Steve Cohen [mailto:[EMAIL PROTECTED] > Sent: Monday, November 17, 2003 12:50 PM > 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 substitution s
> From: peter reilly [mailto:[EMAIL PROTECTED] > > 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} > [X] some thing else, as [EMAIL PROTECTED] I.e. similar to XSLT. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] macrodef - do attributes as properties or substitution s
> 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]
RE: [VOTE] macrodef - do attributes as properties or substitution s
> OK, how do we want to implement attributes: [ ] as textual substitution [X] as "real" Ant properties Jan