----- Original Message ----- From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]> To: "! nant" <[EMAIL PROTECTED]> Sent: Monday, February 23, 2004 12:08 AM Subject: [nant-dev] Implicit conversions in expressions
> Hi! > > We currently have a problem where implicit conversions allowed in NAnt > expressions aren't too intuitive (sometimes they are ambiguous) and we > should do something about it. > > I've analyzed the sources and we have the following conversions: > > c1) when at least one argument to a '+' operator is a string, the operation > is considered a string concatenation and the other argument is implicitly > converted to a string. > > c2) when at least one argument to a '+' operator is a double, the operation > is considered a floating point addition and the other argument is implicitly > converted to a double. > > c3) when at least one argument to a '+' operator is a int, the operation is > considered a integer addition and the other argument is implicitly converted > to an int. > > c4) same as c2 but for '-' operator (subtraction) > > c5) same as c3 but for '-' operator > > c6) same as c2 but for '*' operator (multiplication) > > c7) same as c3 but for '*' operator > > c8) same as c2 but for '/' operator (division) > > c9) same as c3 but for '/' operator > > c10) same as c3 but for '%' operator (modulus - no floating point modulus) > > c11) arguments to "and", "or", "not" are implicitly converted to boolean > > c12) first argument to if() is implicitly converted to boolean > > c13) arguments to functions are implicitly converted to their appropriate > formal types It does look a bit strange to have conversion functions that only convert a double to a double though ... Wouldn't it have been better to support overloads and no longer implicitly convert arguments to functions ...Nah, it would probably complicate things all to much ... > > I suggest the following change: > > c1,c2,c3) both arguments must be of the same type, otherwise the operation > fails. > c4-c10) remain unchanged, considering new definition of c1-c3 > c11-c13) remain unchanged > > This removes any ambiguity from the expression evaluation, but may require > more verbose expressions. The situation will be fixed ultimately only when > we have typed (non-string) properties. Looks good to me ... We (I added this recently) currently also allow an implicit conversion of null to a (empty) string, which is useful for functions that return reference types (eg. framework::get-runtime-engine()). Should we keep this, or do you want to add a "is-null()" function (in what namespace) and a conversion function from null to (empty) string ? That reminds me : we need to document the return type of functions too in the generated docs ... Gert ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
