My first inclination is towards A for Q1. This would mean that all
expressions, and property expansions, are like this ${<expr>}, correct?
XSLT uses braces for inline evaluation in attributes and XPath variables are
"$" prefixed. In our case it seems like once we start a expression block,
denoted by "${", we can assume that everything is either a data type, a
variable identifier, or a function. This seems backwards compatible, and
fairly easy to identify in the build file and tasks. This means that for Q2
I'd also lean towards this syntax (choice A).
As for property names, it seems like a documented standard is a good way to
go. I'm pretty happy with whatever standard we come up with; which is
probably going to be driven by the expression eval. engine.
Now for the larger question, Does everyone want expression support in NAnt?
I think there are some real benefits to adding expression support. It will
make things much more flexible. But it also means that more complicated and
possibly harder to read build files can be built. I don't want to inundate
our users with features that could make maintenance harder.
----- Original Message -----
From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>
> One more thing which I forgot:
>
> Q1 there's a problem where:
>
> B: ${$propertyname} and ${propertyname}
> C: ${${propertyname}} and ${propertyname}
>
> both are legal forms to express a property. Variant A has no such problem.
>
> Jarek
> ----- Original Message -----
> From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>
> > Hi Scott,
> > As you requested, here's a summary of expression evaluator discussion:
> >
> > Ian, Gert, Martin - can you please correct me if I'm wrong anywhere in
the
> > summary.
> > ========================================================
> > There are 2 questions:
> >
> > QUESTION 1:
> > How should expressions be written?
> >
> > A) <echo message="aaa" if="${length(propertyname)=3}" />
> > B) <echo message="aaa" if="${length($propertyname)=3}" />
> > C) <echo message="aaa" if="${length(${propertyname})=3}" />
> >
> > Variant A - is clean and compatible with current approach to accessing
> > properties. Properties can still be accessed as ${propertyname}.
> >
> > This may have the following problems:
> >
> > - it may be hard to distinguish between property and function names
> because
> > they only differ by () (Java, C#, C++ also have this problem).
> > - we may no be able to access some properties (like
> > nant.task.cvs-checkout.location) because they contain dashes which
cannot
> be
> > distinguished from "minus" operator. "a-b" could either be "a" MINUS "b"
> or
> > a property named "a-b". Fortunately there are only 6 such properties in
> NAnt
> > (so this could be quite easily resolved):
> >
> > nant.tasks.cvs-update
> > nant.tasks.cvs-checkout
> > nant.tasks.delay-sign
> > nant.tasks.cvs-update.location
> > nant.tasks.cvs-checkout.location
> > nant.tasks.delay-sign.location
> >
> > There was a suggestion to disallow such property names and formally
define
> > them as:
> >
> > property name => identifier { DOT identifier } *
> > identifier => [a-zA-Z_][a-zA-Z0-9_]*
> >
> > In English:
> >
> > "property name" is a sequence of "identifiers" separated by dots
> > "identifier" starts with a latin letter or an underscore and contains
only
> > letters, digits underscores (like in C#, C++, Java, VB, JavaScript...)
> >
> > - we may not be compatible with property names which are numeric. I was
> told
> > that currently a property can be named "1234". There seems to be an
> > agreement that this should be disallowed asap. I suggest that we
disallow
> > properties containing dashes in their names at the same time.
> > - one could always use use propertyvalue('propertyname') function to
> access
> > weird-names properties
> >
> > Variant B - prefix properties with '$' - similar to PERL
> >
> > - is still quite clean, yet there are some dollars starting to appear
> > - this solves the first problem (the properties can be distinguished
> because
> > they are prefixed with $)
> > - accessing properties with dashes can still be tricky:
> >
> > $property-name-with-dashes // access property
> > $property-name-with-dashes(1) // $property-name-with MINUS dashes(1)
> >
> > Variant C - enclose properties in ${...}
> >
> > - it's difficult to read, especially when using proportional font,
> > - it's unambiguous
> > - no problem accessing any property
> >
> > Opinions on Q1:
> >
> > Jarek: A
> > Martin: A
> > Ian: A or B
> > Gert: B or C
> >
> > QUESTION 2:
> > Should we always require ${} (or anything else we use for quoting) to be
> > written around expressions, or should we allow unquoted expressions in
> some
> > places?
> >
> > Variant A (quote all expressions)
> >
> > <if test="${length(someproperty)=3}">
> > ...
> > </if>
> >
> > <echo message="test" if ="${length(someproperty)=3}" />
> > <echo message="test" unless ="${length(someproperty)=3}" />
> >
> > - it's simple
> > - you ALWAYS use quotes around expressions (both embedded in strings and
> > stand-alone)
> > - you can easily spot the expressions in your build file
> > - this may allow for easy implementation of syntax highlighting
(actually
> I
> > already did this for VIM)
> >
> > Variant B: allow for unquoted expressions in some places where
non-string
> > values are expected:
> >
> > Like "<if test="..." /> <... if="..." /> <... unless="..." />
> >
> > <if test="length(someproperty)=3">
> > ...
> > </if>
> > <echo message="test" if="length(someproperty)=3" />
> > <echo message="test" unless="length(someproperty)=3" />
> >
> > - this is somewhat more readable (less dollars)
> > - it may be hard to find expressions in the build file.
> > - it may not be clear when to use quotes and when not to use them
> >
> > Variant C: skip quotes for <if test="..." /> - keep for everything else
> >
> > - this is implemented in "test1"
> >
> > Opinions on Q2:
> >
> > Jarek: A
> > Martin: A
> >
> > CURRENT STATUS:
> >
> > 1. Expression evaluator is in CVS in branch "EE-patches"
> > 2. It implements variants: Q1:A and Q2:C
> >
> > A binary release of this is available at
> >
> > http://jaak.sav.net/nant-ee/nant-ee-test1.zip
> >
> > It contains some test cases written as a build file.
> >
> > Jarek
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
