I certainly agree that the proposed syntax is cleaner and having used the current implementation I think it works well and fits into the existing framework without needing existing scripts to change. It will be a shame it we have to rename tasks with a - in their names but if there are only 6 of them that is probably acceptable. I'd rather change the names and dissallow dashs as well then revert to using the propertyvalue('nant.tasks.cvs-checkout.location') syntax which is kinda klunky.

Ian

Jaroslaw Kowalski wrote:

Hi Gert,

As we're awaiting Scott's opinion on the subject, I have more arguments:

1. Assuming we used $propertyname the proper way to specify properties
inside expressions would be:

${$propertyname}

while currently supported syntax is:

${propertyname}.

Should we get rid of ${propertyname} syntax and change it to
${$propertyname}? It's very difficult IMO.
Introduce another magic tag for specifying expressions? %{$propertyname}.
You could then either use %{$propertyname} or ${propertyname}. Ugly - I
think.

2. Assuming we used ${propertyname} we have the same problem - there are two
legal ways to access properties, which may lead to confusion:

${propertyname} - current form
${${propertyname}} - expression whose value is the value of the
"propertyname" property

It's also more difficult to parse and you cannot use regular expressions
here because regexes cannot support balancing nested braces.

3. Notation proposed by Martin and implemented by me in test1 doesn't have
these problems:

It's compatible with today's approach to accessing properties (modulo the
mentioned problem with dash character). It allows for easy introduction of
functions and arithmetic expression without uglifying (dollarizing ;-) NAnt
scripts.

BTW. Assuming we have expression evaluator in place, we could get rid of
"nant.tasks.TASKNAME" syntax at all by replacing it with a function, like
"taskexists('taskname')". Similar approach could be used to check for
location of the task: "tasklocation('taskname')" instead of
"nant.tasks.TASKNAME.location". Assuming this, there would be no need to
have properties with dashes in them.

Jarek
----- Original Message ----- From: "Gert Driesen" <[EMAIL PROTECTED]>
To: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>; "Ian MacLean"
<[EMAIL PROTECTED]>; "Martin Aliger" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, December 05, 2003 12:12 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt





Aren't we making this too difficult for ourselves and for our users here,


by


not using the $ or ${} delimiters ?

Perhaps I'm alone on this, but I really have serious doubts on this ...

Gert

----- Original Message -----
From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>
To: "Ian MacLean" <[EMAIL PROTECTED]>; "Martin Aliger"
<[EMAIL PROTECTED]>
Cc: "Gert Driesen" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Friday, December 05, 2003 12:00 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt




One more think came to my mind:

Dash ("-") is a legal character in property name today and this may


cause


problems with expression evaluator because you cannot tell the


difference


between:

property1 MINUS property2 (written as property1-property2)
and
very DASH long DASH property DASH name (written as


very-long-property-name)


I've run "script-sample.build" from examples directory and found that


there


are actually 6 properties with dashes in their names:

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

Do you think we should do anything special to handle them?
EE currently supports propertyvalue() function where you can specify
property name as a string (so no quoting problems will arise). So for


these


special properties you would have to write, e.g:

<if



test="${contains(propertyvalue('nant.tasks.cvs-checkout.location'),'c:\windo


ws')}">
   <echo message="zzz" />
</if>

Is it ok?

Jarek

----- Original Message -----
From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>
To: "Ian MacLean" <[EMAIL PROTECTED]>; "Martin Aliger"
<[EMAIL PROTECTED]>
Cc: "Gert Driesen" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, December 03, 2003 4:26 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt




Can we define properties as:

property name => identifier { separator identifier } *
separator =>  "." | "-".
identifier => [a-zA-Z_][a-zA-Z0-9_-]*

In English:

"property name" is a sequence of "identifiers" separated by


"separator"s


"separator" is a dot
"identifier" starts with a latin letter or an underscore and contains


only


letters, digits underscores or dashes.

This may affect people using property names with non-latin characters.

Jarek

----- Original Message -----
From: "Ian MacLean" <[EMAIL PROTECTED]>
To: "Martin Aliger" <[EMAIL PROTECTED]>
Cc: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>; "Gert Driesen"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, December 03, 2003 3:20 PM
Subject: Re: [nant-dev] PATCH: Expression evaluator for NAnt




Is anyone actually using numeric property names ? I say we should
dissallow them and be done with it.

Ian

Martin Aliger wrote:



- it won't break compatibility for properties with numeric names


(eg




${123})
Can you have properties with such names? What's the use for them?


Maybe




they




should be disallowed or deprecated?




What about output warning when defining property with such name?
that is on <property name="123" value="whatever"/> outputs


something


like:


[property] warning: define property with numeric name is not


recomended.


[or


is deprecated.]

Martin





------------------------------------------------------- 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




------------------------------------------------------- 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





------------------------------------------------------- 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





--
Ian MacLean, Developer, ActiveState, a division of Sophos
http://www.ActiveState.com





------------------------------------------------------- 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

Reply via email to