Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Message-ID: <879A5AD5DD0ED511891F0003473A9B5608FF72DC@Z011004>
From: Jan.Materne@rzf.fin-nrw.de
To: dev@ant.apache.org
Subject: RE: [VOTE] macrodef - do attributes as properties or substitution
	 s
Date: Thu, 20 Nov 2003 07:20:42 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3AF2E.6CE0BCD0"

------_=_NextPart_001_01C3AF2E.6CE0BCD0
Content-Type: text/plain;
	charset="iso-8859-1"

> 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 "{@x}" 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:jalberto@cellectivity.com]
> > > > From: Gus Heck [mailto:gus-antdev@cognition.olin.edu]
> > > > 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!!!
> >
> >{@x} 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 {@x} 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 {@x} 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: dev-unsubscribe@ant.apache.org
> >For additional commands, e-mail: dev-help@ant.apache.org
> 
> =============================================================
> J. Kenneth Gentle (Ken)    | Phone: (610) 255-0361
> Gentle Software, LLC       | Email: j.kenneth.gentle@acm.org
> =============================================================
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
> 

------_=_NextPart_001_01C3AF2E.6CE0BCD0--