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
