> From: Peter Reilly [mailto:[EMAIL PROTECTED] > I have not been able to respond as my work commitments > are extreme at the moment. > > I do not like roles (although I did write an implementation) > as it would be like the following in a language: > > Integer x = 1; > Complex x = (8, 10); > > Complex z = (-1, 9); > > Complex y = x + z; > > The compiler in this case knows which "x" to pick > based on the context.
I think that's the wrong analogy Peter. It's not so much that Ant would pick the correct instance to use, but more to pick the correct class of instances. I did write about binding several different impls/roles under the same name with auto-selection based on context, but it may indeed not be a good idea. The correct analogy in my mind is trying to use two similarly (short) named classes, from different packages. In which case you must disambiguate them with the package name (at least one of them in Java can be imported, the rest need full qualification). > I do not know any language like that (I am sure that > there are a few!) but I feel it would be confusing to > users. For the simple case of getting the correct "and", it > may not be too bad, but the feature could be misused and > people could wind up with impossible to debug build > scripts. > > I do not using XML namespaces to denote ant core types. > Traditionlly ant build files have been free of namespaces (until > ant 1.6 they were not possible). I guess that's were there's a communication breakdown. All I'm saying is that an antlib per-role allows use of the add(Type) methods, especially in 3rd party antlibs. Ant barely uses these methods. We just need a way to unambiguously specify which role impl to use. AntLibs, which can be declared and use thru XML namespaces (but don't need to!) are a natural choice. Roles are not Ant types. They shouldn't be. They're little strategy classes for somebody else to use, not full fledge tasks/types. > It has been IMO a reason for > ant's success (see the demise of jelly). The build files are > easy-to-read - and free of clutter. The demise of Jelly has probably more to do with the fact that it was a real programming language with an Ugly XML syntax. Ant has kept mostly declarative, and thus does not suffer the same ills. > Using XML namespaces > are fine for using a small number of external antlibs - One doesn't need to use XML namespaces to use AntLibs > I would have preferred a simple prefixing mechanism (water > under the bridge now). It was becoming obvious to me you had second thoughts... I do not share your doubts obviously (maybe it's my use of XSL), but nothing prevents you from adding a prefix attribute to taskdef/typedef (isn't there one already?). Finally, I'd like to remind everyone that what I was asking all along, and still propose, is simply to have a few XML resource files added to Ant. There are absolutely *zero* Ant source code changes necessary!!! Except if as Matt proposes we offer a shortcut to accessing these XML resources. So can we please have at least these resources? I'd even do it if we can get some sort of agreement here, or more precisely if we don't get any -1. --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
