> -----Original Message----- > From: Gert Driesen [mailto:[EMAIL PROTECTED] > > ----- Original Message ----- > From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]> > > > On Wed, 21 Jul 2004, Troy Laurin wrote: > > > > The destination type is "string" > > unless overriden by "type" attribute. This is what most > > people expect from assignment operation (in languages > > like C++, C#, Java ...) > > > > > <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? > > > > "string"
Why I brought up these examples is that it is actually quite different from behaviour in most compiled languages, in that the _value_ is determining type... in most compiled languages, the _property_ (variable) determines type. Of course, scripting/interpreted languages often use value-determined type to good use... at the cost of very weak (or nonexistant) type checking. > > > 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 > > > > Property's type is always "string" unless specifically > > overriden. Simple. The problem arises in that the property's type may be set somewhere distant in the build file, and then it's not apparent when looking at the _use_ of the build file what the property's type is... so you don't know if you're going to get a conversion exception or not until you actually run the build. > > All implicit conversion will be disabled and will cause an error > > requiring you to fix your build file. > > > > > 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! > > > > Yes, but there's been no stable release of NAnt + > > expressions. Good point :-) The nightly builds have been pushed quite strongly on the mailing lists... but it would be simple to notify the lists that expressions would need to be updated. > > > 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. > > what about, for example, datetime values ? we currently > support the additional of datetime and timespan values ... That's not in the documentation! :-) I think that still works okay... because datetime and timespan can't be converted (implicitly or explicitly!) to int or float, '+' can be safely overloaded to date/time addition (and '-' to date/time subtraction) without ambiguity. Of course, whether it's a good idea to support operator overloading (whether safe or not) is a separate question. A simple, though not necessarily optimal, "fix" would be to remove the date-related "overloads" on the operator, and instead use datetime:: functions. One benefit to using functions rather than operators is that it's immediately obvious whether you're incrementing the date or the time. > > 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. > > > > I like the idea. We could replace '+' with a '.' as it is > > used in PERL or PHP for example. Alternatively we could > > have string::concat(...) for this purpose but this would be > > too verbose. I agree that string::concat is far too verbose for common use. '.' as the concatenation operator was actually my first thought, as you mentioned for its current use in Perl/PHP... but then I wondered what the syntax would be when trying to concat the property 'str.prefix' with 'file.name', hence my suggestion of | (I think | or || is the string concatenation operator in Oracle SQL, if anyone wanted a link to an existing language ;-) Alternatively, it could be required that operators are surrounded by whitespace. (Basically upgrading the recommendation that operators are surrounded by whitespace that's currently in the documentation) > > > Would just this last be enough type safety? It still includes > > > implicit conversion from string to int/float, but in a > (IMHO) safe fashion. > > > > After some thought, I give this idea (using concatenation operator > > other than a plus) +1. Gert, what do you think? This would > solve 99% > > of all ambiguity problems without the need for typed properties. > > Think I still need to give it some more thought ... I'm in > "holiday" mode today ;-) > > Gert Regarding Malcolm's comment that typed properties shouldn't get in the way of the up-and-coming 0.85 release, I very much agree... but there's also the fact that this discussion is somewhat aided by the fact that, as Jarek commented, there currently isn't a stable release with expressions. After this, breaking people's build files on upgrade becomes much more of a nuisance... although good release notes specifying how to fix such breakages go a long way to ameliorating this. 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. ------------------------------------------------------- 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_idG21&alloc_id040&op=click _______________________________________________ Nant-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-users
