RE: [nant-dev] Typed properties
Untyped properties certainly have many drawbacks. When we (you - mainly
:) introduced expressions I give some advices/experience from mine scripting
engine. For typed properties I have simmilar feeling as you - many drawbacks.
Then I introduce types - just string,number and datetime. BUT up to now it is
not used much. From users point of view use of convert:: functions and store
everything as string is enough!
So -
introduce of types could be nice thing but do not give it much priority. I think
there is much much more important things.
btw:
what about to intergrate system of properties with "types" (mainly filesets atm)
? E.g. to define named fileset to write something like
Martin
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jaroslaw KowalskiSent: Tuesday, July 20, 2004 12:45
PMTo: [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:
...
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:
When "type" is omitted - "string" is assumed by default for
compatibility.
The following would fail because of incompatible types:
Assuming we disallow all implicit conversions:
-- causes an error, today it
outputs 'TrueFalse'
--- causes an error, today it
outputs aaaFalse
--- outputs
aaaFalse
-- outputs 444, today it outputs
123321
-- fails, currently it outputs
123456
-- outputs
123456
-- outputs
579
Implicit conversion would still be applied when passing arguments to
functions:
Assuming
int fun(int k) { return k; }
-- 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
Re: [Nant-users] Re: [nant-dev] Typed properties
--- Gert Driesen <[EMAIL PROTECTED]> wrote: > From: "Malcolm MacLucas" <[EMAIL PROTECTED]> > > After thinking about it for a bit, I'll repeat what I said earlier, Typed > > properties would be cool. > > > > That being said, I think that it should be looked at and placed on the > road map > > somewhere down the road. Around .87 or .88. > > Not sure, we really should make sure we don't have to break people's build > files when we introduce typed properties at that stage ... Gert, you are right, my bad, I meant, "I think that it should be looked at and <<< if approved by the design team, >>> placed on the roadmap somewhere down the road. Around .87 or .88 <<< but, in my estimation, not any sooner. >>>. Very critical omissions on my part. > > what they want to work on. ... Some of the project management tasks are > very > > "un-sexy", tedious and pretty much not rewarded. > > I've spent a good part of the day doing this un-sexy work : a first draft of > the release notes for NAnt 0.85 beta 1 is in cvs ... Thanks Gert, that work tends be be something that no one notices if it's done right, but everyone complains about if its even slightly off. Same tends to go for technical writing. As a side note, I have got to figure out how to use CVS. Anyone have a preference for a cvs how to that will have me up and running in 15 - 20 minutes from end of download? > > > > We are an Agile development tool, I'm thinking that we have the chance to > > demonstrate the value of an agile methodology (multiple incremental > builds, > > always in a stable state) > > > > What would it take for us to put out a release candidate, on say, August > 4th, > > that gives us 2 weeks to make it happen. > > Sure, see no problem with that ... Cool, again, any thing I can do to help, even if I have to submit the stuff to you via e-mail, I love what is possible with NAnt and want to get it into the hands of busy end users that are looking for a simple solution to solve their needs. A solution that they can get running in 15-20 minutes from the time they finish their download. > > > > > Speaking of which, I have not been able to find the roadmap, or vision > document > > for NAnt. Can someone point me in their direction? > > There isn't really one, except for the release plan (and even that is not > something that has been discussed very much) ... ?release plan? Where do I find that? Let me guess, there's a "documents" section in the CVS isn't there? Thanks again. Malcolm = "Oh Bother!" said the Borg, "We just assimilated Pooh." __ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/ --- 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
Re: [Nant-users] Re: [nant-dev] Typed properties
After thinking about it for a bit, I'll repeat what I said earlier, Typed properties would be cool. That being said, I think that it should be looked at and placed on the road map somewhere down the road. Around .87 or .88. We have been 7 months without a "release". We can't keep adding new features and hope that they will go in with no problems and or side effects. At the same time, this is a volunteer effort so the reality is that people only have a limited amount of time and that for the most part, people are going to work on what they want to work on. ... Some of the project management tasks are very "un-sexy", tedious and pretty much not rewarded. We are an Agile development tool, I'm thinking that we have the chance to demonstrate the value of an agile methodology (multiple incremental builds, always in a stable state) What would it take for us to put out a release candidate, on say, August 4th, that gives us 2 weeks to make it happen. Speaking of which, I have not been able to find the roadmap, or vision document for NAnt. Can someone point me in their direction? Thanks Malcolm --- Jaroslaw Kowalski <[EMAIL PROTECTED]> wrote: > 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... > > > > > 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. = "Oh Bother!" said the Borg, "We just assimilated Pooh." __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail --- 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
RE: [Nant-users] Re: [nant-dev] Typed properties
> -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 ...) > > > > > > > > > > > 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
Re: [Nant-users] Re: [nant-dev] Typed properties
Gert Driesen wrote: - Original Message - From: "Malcolm MacLucas" <[EMAIL PROTECTED]> To: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>; "Troy Laurin" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, July 21, 2004 9:02 PM Subject: Re: [Nant-users] Re: [nant-dev] Typed properties After thinking about it for a bit, I'll repeat what I said earlier, Typed properties would be cool. That being said, I think that it should be looked at and placed on the road map somewhere down the road. Around .87 or .88. Not sure, we really should make sure we don't have to break people's build files when we introduce typed properties at that stage ... Yeah but on the other hand we shouldn't go rushing in features because we're worried about breaking builds later on. Two points : firstly we are reccomending that people use nightly builds *now* which means that they'll get broken builds anyway and secondly, the amount of changes since 0.84 means that updrading users will get a slew of deprecated messages. Thats not a big problem but I mention it to make the point that upgrading will have a 'cost' regardless of which release we target features too. My view is that adding typed properties is a significant change with the potential to add complexity to builds. I can see the problems that can be solved by their addition but I'm not yet convinced that they are sufficent justification. It seems to me that it will be more complicated than just adding a type attribute. What types will we support ? just basic string, int, bool etc or the full CLR type system ? Ian --- 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
Cvs how-to; was: RE: [Nant-users] Re: [nant-dev] Typed properties
Hi Malcolm, You can try downloading TortoiseCVS (http://www.tortoisecvs.org/download.shtml) which should make basic cvs work painless. It provides shell integration and an intuitive gui for checkouts and updates. If you look at the user's guide (http://www.tortoisecvs.org/UserGuide_en.chm) "Checking out a Module" and the NAnt cvs information on the project page (http://sourceforge.net/cvs/?group_id=31650) it should get you up and running fairly quickly. You will have read only access to the NAnt repository with the anonymous user which is not optimal if you are doing frequent updates but you should be able to generate patch files and submit them to the list. If your updates are frequent enough it might be worthwhile to get committer access. Hope that helps. Cheers, Clayton > -Original Message- > From: Malcolm MacLucas [mailto:[EMAIL PROTECTED] > Sent: July 21, 2004 1:24 PM > To: Gert Driesen; Jaroslaw Kowalski; Troy Laurin; > [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: [Nant-users] Re: [nant-dev] Typed properties > > > --- Gert Driesen <[EMAIL PROTECTED]> wrote: > > From: "Malcolm MacLucas" <[EMAIL PROTECTED]> > > > After thinking about it for a bit, I'll repeat what I > said earlier, > > > Typed properties would be cool. > > > > > > That being said, I think that it should be looked at and > placed on > > > the > > road map > > > somewhere down the road. Around .87 or .88. > > > > Not sure, we really should make sure we don't have to break > people's > > build files when we introduce typed properties at that stage ... > > Gert, you are right, my bad, I meant, > "I think that it should be looked at and <<< if approved by > the design team, > >>> placed on the roadmap somewhere down the road. Around .87 or .88 > >>> <<< but, > in my estimation, not any sooner. >>>. > > Very critical omissions on my part. > > > > what they want to work on. ... Some of the project management > > > tasks are > > very > > > "un-sexy", tedious and pretty much not rewarded. > > > > I've spent a good part of the day doing this un-sexy work : a first > > draft of the release notes for NAnt 0.85 beta 1 is in cvs ... > > Thanks Gert, that work tends be be something that no one > notices if it's done right, but everyone complains about if > its even slightly off. Same tends to go for technical writing. > > As a side note, I have got to figure out how to use CVS. > Anyone have a preference for a cvs how to that will have me > up and running in 15 - 20 minutes from end of download? > > > > > > > We are an Agile development tool, I'm thinking that we have the > > > chance to demonstrate the value of an agile methodology (multiple > > > incremental > > builds, > > > always in a stable state) > > > > > > What would it take for us to put out a release candidate, on say, > > > August > > 4th, > > > that gives us 2 weeks to make it happen. > > > > Sure, see no problem with that ... > > Cool, again, any thing I can do to help, even if I have to > submit the stuff to you via e-mail, I love what is possible > with NAnt and want to get it into the hands of busy end users > that are looking for a simple solution to solve their needs. > A solution that they can get running in 15-20 minutes from > the time they finish their download. > > > > > > > > Speaking of which, I have not been able to find the roadmap, or > > > vision > > document > > > for NAnt. Can someone point me in their direction? > > > > There isn't really one, except for the release plan (and > even that is > > not something that has been discussed very much) ... > > ?release plan? Where do I find that? Let me guess, there's > a "documents" section in the CVS isn't there? > > Thanks again. > > Malcolm > > > = > "Oh Bother!" said the Borg, "We just assimilated Pooh." > > > > > __ > Do you Yahoo!? > Vote for the stars of Yahoo!'s next ad campaign! > http://advision.webevents.yahoo.com/yahoo/votelifeengine/ > > > --- > 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 > --- 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-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [Nant-users] Re: [nant-dev] Typed properties
- Original Message - From: "Malcolm MacLucas" <[EMAIL PROTECTED]> To: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>; "Troy Laurin" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, July 21, 2004 9:02 PM Subject: Re: [Nant-users] Re: [nant-dev] Typed properties > After thinking about it for a bit, I'll repeat what I said earlier, Typed > properties would be cool. > > That being said, I think that it should be looked at and placed on the road map > somewhere down the road. Around .87 or .88. Not sure, we really should make sure we don't have to break people's build files when we introduce typed properties at that stage ... > > We have been 7 months without a "release". We can't keep adding new features > and hope that they will go in with no problems and or side effects. At the > same time, this is a volunteer effort so the reality is that people only have a > limited amount of time and that for the most part, people are going to work on > what they want to work on. ... Some of the project management tasks are very > "un-sexy", tedious and pretty much not rewarded. I've spent a good part of the day doing this un-sexy work : a first draft of the release notes for NAnt 0.85 beta 1 is in cvs ... > > We are an Agile development tool, I'm thinking that we have the chance to > demonstrate the value of an agile methodology (multiple incremental builds, > always in a stable state) > > What would it take for us to put out a release candidate, on say, August 4th, > that gives us 2 weeks to make it happen. Sure, see no problem with that ... > > Speaking of which, I have not been able to find the roadmap, or vision document > for NAnt. Can someone point me in their direction? There isn't really one, except for the release plan (and even that is not something that has been discussed very much) ... 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
Re: [Nant-users] Re: [nant-dev] Typed properties
- 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... > > > > > > > > > > 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 ...) > > > > > > > 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 > 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: > > -- type=string > -- type=integer > -- type=boolean > -- type=string > -- type=string > -- 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
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... > > > > > 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 ...) > > > 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 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: -- type=string -- type=integer -- type=boolean -- type=string -- type=string -- 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-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Typed properties
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...
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?
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 KowalskiSent: Tuesday, 20 July 2004 6:45
PMTo: [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:
...
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:
When "type" is omitted - "string" is assumed by default for
compatibility.
The following would fail because of incompatible types:
Assuming we disallow all implicit conversions:
-- causes an error, today it
outputs 'TrueFalse'
--- causes an error, today it
outputs aaaFalse
--- outputs
aaaFalse
-- outputs 444, today it outputs
123321
-- fails, currently it outputs
123456
-- outputs
123456
-- outputs
579
Implicit conversion would still be applied when passing arguments to
functions:
Assuming
int fun(int k) { return k; }
-- 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.
JarekDisclaimer 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.
