On Wed, 21 Jul 2004, Troy Laurin wrote:
> 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?
The idea is that the type conversion occurs AFTER the value has been
evaluated and BEFORE the value is stored. 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"
HOWEVER: We could be smart (or dumb - pick one) by introducing the
following rule: If the value of the property already has a type and
<property> doesn't specify a type - use the resulting type. In this case
the answer would be "integer". This can be confusing, though:
Some examples of inferenced types:
<property name="a" value="1" /> -- type=string
<property name="a" value="${1}" /> -- type=integer
<property name="a" value="${true}" /> -- type=boolean
<property name="a" value="true" /> -- type=string
<property name="a" value="tru${'e'}" /> -- type=string
<property name="a" value="${false}z" /> -- type=string
> 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.
Property's type is always "string" unless specifically overriden. Simple.
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. We've had a
discussion with Gert some time ago and agreed we need to get rid of
implicit conversions by the time 0.85 ships.
> 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.
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.
> 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.
Jarek
-------------------------------------------------------
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
