>From a user point of view, I love it.
I'm not currently doing anything with NAnt that would require this much power,
but it would be nice to have.
Malcolm
--- Jaroslaw Kowalski <[EMAIL PROTECTED]> wrote:
> 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.
>
> Jarek
=====
"Oh Bother!" said the Borg, "We just assimilated Pooh."
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
Nant-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-users
