I whole-heartedly agree! Although non-typing will undoubtedly add more complexity to the NAnt core code, it would, in many instances, simplify life for the user. The ultimate goal for any software should be to simplify the life of the user.
Certainly, having the power to use .NET constructs as part of expressions would be powerful, but that functionality, perhaps, should only exists as part of the <script> task and the extensibility capabilities of NAnt. Some rudimentary expression support is good to extract information for things that NAnt users need. Adding too much power to expressions is bad because an expression quickly becomes overly complex making the life of the maintainer very difficult, regardless of whether the maintainer has programming experience or not. I like the idea of NAntContrib. A repository containing extra "stuff" that perhaps should not be part of the main/core distribution. Perhaps what is needed is a centralized bucket where community members can dump scripts and custom tasks that could be useful to other people. This could be a place where NAnt users can use as a powerful reference for their own custom extensions or simple to get a script that does something they need. Anyone should be allowed to contribute. I think expressions have their place because there are many instances where the use of a function is extremely valuable to extract some information. Tasks are not very good for this because it's not obvious that some result of executing the task is that at property is set. That's the job of the <property> task. If I need to do something complex and store the result in a property then I should use a script or a custom function as part of an assembly. I personally write custom functions when I need to extract information from something. For example, I have an xml file that lists all of my vss projects. The <xmlpoke> task would be perfect to get at that information, but it doesn't support looping easily. So I use a custom function to mimic the <xmlpoke> task, get the nodeset I need and format it in a way that allows me to format it with other tasks. Returning a .NET NodeSet is not very useful but returning some textual representation is because I can use <foreach> to process each item in the set. I've seen other people have this need. If I'd had a community script bank to look into I could've simply used someone's script rather than write my own. In any case, the expression capability in NAnt allows me to use the custom function in a way that makes sense because I can store the output in a property or use it as the value for a task attribute. I some times feel that NAnt is quickly becoming too complex to use, at the same time the nightly builds have a lot of functionality that is impossible with earlier versions (custom functions) or bug fixes that are necessary for correct execution... I put up with the complexity because I have to rather than because I want to! --Edwin -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Merrill Cornish Sent: Friday, October 08, 2004 9:01 AM To: [EMAIL PROTECTED] Subject: [Nant-users] Typed Properties When I saw earlier posts about typed properties, I didn't pay much attention. Since typed languages are a Generally Good Thing, adding typed properties to NAnt sounded like a good thing too. Now, after my run in with the assembly/assemblyname beast, I'm not so sure. The typing mechanism in typed languages carries a _lot_ of baggage: type hierarchies, implicit/explicit type conversion, type incompatibilities, and so on. On the other hand, scripting languages such as shell scripts, Perl, and the original NAnt don't have types. Instead, everything tends to be passed around as a string and interpreted as something else (e.g., "123" is really an integer) based on context. It is this lack of explicit typing that makes scripting languages so easy to use (at least for simplier work). I worry that if NAnt were to add typing, instead of that being one step forward, it might be one step over the edge of a cliff. Take a look at the assembly::* and assemblyname::* functions. While load-from-file() represents a true action, all of the others basically extract string information (or could be defined to extract string information) from an assembly (e.g., name, full name, version, URI, URL, etc.) What usefulness does all of this typing baggage bring to those functions? Talking in vague generalities about all of the "power" of the notation is beside the point. For what NAnt users need _now_, what does that typing add other than total confusion? I would agrue that we need to consolidate typeless, string-oriented NAnt for now, and only move into the power (and complexities) of a typed system later. If nothing else, a typed system is going to require one _heck_ of a lot more documentation than a half line of text after each function name. Merrill ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Nant-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-users ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Nant-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-users
