|
Untyped properties certainly have many drawbacks. When we (you - mainly
:) introduced expressions I give some advices/experience from mine scripting
engine. For typed properties I have simmilar feeling as you - many drawbacks.
Then I introduce types - just string,number and datetime. BUT up to now it is
not used much. From users point of view use of convert:: functions and store
everything as string is enough!
So -
introduce of types could be nice thing but do not give it much priority. I think
there is much much more important things.
btw:
what about to intergrate system of properties with "types" (mainly filesets atm)
? E.g. to define named fileset to write something like
<property name="a" type="fileset>
<value>
<include name="**"/>
</value>
</property>
Martin
Hi guys!
I'd like to propose the introduction of typed
properties to NAnt. Currently properties are stored as strings which has many
drawbacks, esp. when used within expressions.
For example:
<property name="a" value="false"
/>
<if test="${a=false}">
...
</if>
this test fails because:
1. "a" is stored as a string
2. equality operator promotes "false" literal to
string which becomes "False" (note the initial cap - this is what
Convert.ToString() does) the compares both sides as strings.
3. 'false' != 'False'
My idea is to:
1. Disallow ALL implicit conversions for
operators - to avoid such confusions
2. Add support for typed properties - to let
properties store values of types other than strings. It would involve type
checking on assignment and type-safe retrieval.
The proposed syntax would be:
<property name="a" type="bool" value="false"
/>
<property name="b" type="int"
value="${1+1234}" />
When "type" is omitted - "string" is assumed by default for
compatibility.
The following would fail because of incompatible types:
<property name="a" type="bool" value="3"
/>
<property name="a" type="int" value="false"
/>
<property name="a" type="float" value="zzz"
/>
Assuming we disallow all implicit conversions:
<property name="a" type="bool" value="true"
/>
<property name="b" type="bool" value="false"
/>
<property name="c" type="int" value="123"
/>
<property name="d" type="int" value="321"
/>
<property name="e" type="string" value="456"
/>
<echo message="${a + b}" /> ------ causes an error, today it
outputs 'TrueFalse'
<echo message="${'aaa' + b}" /> --- causes an error, today it
outputs aaaFalse
<echo message="${'aaa' + convert::to-string(b)}" /> --- outputs
aaaFalse
<echo message="${c + d}" /> ------ outputs 444, today it outputs
123321
<echo message="${c + e}" /> ------ fails, currently it outputs
123456
<echo message="${convert::to-string(c) + e}" /> ------ outputs
123456
<echo message="${c + convert::to-int(e)}" /> ------ outputs
579
Implicit conversion would still be applied when passing arguments to
functions:
Assuming
int fun(int k) { return k; }
<echo message="${fun(e) + 1}}" /> ------ outputs 457
There are probably more consequences of this idea, if you see any danger
- let me know.
I'm awaiting your comments. If this idea passes, I'll prepare the
appropriate patch. Initial feasibility study shows that it's possible to
do it without breaking compatibility.
| 