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 (local 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 macrodef 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 macrodef 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
macrodef 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 macrodef 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 macrodef 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
macrodef 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
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
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
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
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 xsl:value select=attributeName/ 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
[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
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
-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
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
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 macrodef 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
OK, how do we want to implement macrodef attributes: [ ] as textual substitution [X] as real Ant properties Jan
RE: [VOTE] macrodef - do attributes as properties or substitution s
From: Stefan Bodewig [mailto:[EMAIL PROTECTED] OK, how do we want to implement macrodef attributes: [X] as textual substitution [ ] as real Ant properties - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
