[Nant-users] RE: [nant-dev] Typed properties

[Troy Laurin]

Jarek, others,   I kind of like the idea of a property having a type, but I have a few questions regarding implementation...   In the following...   <property name="a" type="int" value="1234" /> <property name="a" value="5678" />   If the default type for properties if none is specified is 'string', then what is the type of 'a' after the two property assignments above?   <property name="a" value="${convert::to-int('1234')}" />   Again, if the default property type is 'string', then what is the type of 'a' after this assignment?     Regarding disallowing all implicit conversions in operators, I can see why you might want this, but I have a feeling that it will be more of a source for error than a means for preventing errors... mostly because it isn't always (often?) going to be apparent by looking at the build file exactly what a property's type is.  I imagine this will lead to people not using types because of the dangers of inappropriate implicit conversion, or guarding against implicit conversion by extensively (excessively) using explicit conversion.   Notwithstanding, "it's possible to do it without breaking compatibility"... you can't claim this if you are making a change that turns a previously valid operation into an error!     Having said the above, there is an alternative to disallowing implicit type conversion (that unfortunately also breaks backwards compatibility) that means that all implicit type conversions should be safe: I've never been a particular fan of overloading the '+' operator with string concatenation... if '+' only means addition, then it would always involve numeric-conversion.  Because there is no implicit conversion from boolean to integer, a boolean operand will cause an error.  Conversely if (for example) '|' means concatenation then it would always involve (unambiguous) string-conversion.   Would just this last be enough type safety?  It still includes implicit conversion from string to int/float, but in a (IMHO) safe fashion.     Regards,   -- Troy   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jaroslaw Kowalski Sent: Tuesday, 20 July 2004 6:45 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [nant-dev] Typed properties 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 Disclaimer Message: This message contains confidential information and is intended only for the individual(s) named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. To the maximum extent permitted by law, Immersive Technologies Pty. Ltd. does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission.