----- Original Message -----
From: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>
To: "Troy Laurin" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, July 21, 2004 9:57 AM
Subject: [Nant-users] Re: [nant-dev] Typed properties
> 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.
What about dynamic properties ? These are not evaluated before they are
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:
Yeah, and we should avoid confusion (and complexity) whenever possible ...
we're already getting enough questions as is ;-)
>
> 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.
I still agree with this, but I'm not the only one to decide upon this
ofcourse ...
>
> > 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 ...
> 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.
Think I still need to give it some more thought ... I'm in "holiday" mode
today ;-)
Gert
-------------------------------------------------------
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-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
