> From: Peter Reilly [mailto:[EMAIL PROTECTED] > I do not like "ant:mappers", etc
I don't have much of a problem with it myself now. It's been argued, winning me over, that the ant: prefix is already reserved, and thus it's an acceptable solution solution to this problem, and Matt idea of loading role.xml for ant:<role> is elegant enough, no? > This does not use the method "antlib:<package name>" that antlibs > are meant to be identified by. If "ant:<whatever core wants>" is > used to identify ant's antlibs', then there is ample reason for > thirdparty antlibs authors to ask for "easy to use" XML uri > identifications for their antlibs. As I wrote earlier I also like the antlib:<package> convention. That's what I proposed we used in the first place. But others think it's too verbose. Surely you can see where they're coming from Peter ;-) > For core ant types, I do not think it is a good idea - the namespace > syntax will "get in the way". Not really. Within Ant itself, you would never need to specify NS for mappers, selectors, etc... Because Ant types using them, instead of having one elegant add(FileSelector) method, they have tons of add<this>(FileSelector). The need for namespaced types arises for 3rd party which do use the more elegant and extensible add(Type) methods! Use a namespace is tons more elegant than having to explicitly typedef each one you want to use like I had to do. If you refuse to add role-specific antlibs, then I'll have to define them myself in my custom AntLib, which clearly breaks encapsulation. > For about a year now, new mappers, conditions, selectors and filters > have been added by making them typedefs. If so, why did I need to typedef the date and size selectors when I'm using Ant 1.6.2? > We should be able to make all the current conditions, selectors and > filters be typedefs. But then you're polluting the global namespace IMHO. Types where originally for elements that could stand on their own at the top level, or directly inside targets. All these new types you are defining in the global namespace OTOH are meant to be used only in a very narrow context, within another (real) type or task. > There are only a few name over-laps: > and, or, not (selectors and conditions) > > Of course this will change with the selectors for the > new resource collections, - but it may be possible to > be clever. Precisely. We already have name conflicts, and it will only get worse. Namespaces are meant to resolve name conflicts. Lets try to not get too clever trying to implement another mechanism for this. > It is quite easy to write a type that is a container for > selectors and conditions (attached) that will act as a > container for selectors or for conditions. It's my turn to not like this. As you say, it's clever, but now you're writing code to disambiguate name clashes, and the more name clashes appear, the more you write code... So to summarize, you Peter don't need to use any namespace when using Ant roles, because you're likely to use then in the context of Ant types/tasks, which have specialized add or create method for them. I, otoh, but using the new flexible add(Type) method, have forced to use namespaced Ant roles (mapper, selector), and that's perfectly alright with me. It is my opinion that Ant roles should *NOT* be added as types (if some were, then for BC reason they can stay that way, but only if they appeared in an official release), to avoid polluting the global namespace. As a consequence, like I said in the first place, we need to define Role-specific AntLibs (and thus namespaces). And I personally don't care if we use ant:<role> or antlib:<package>. What I wanted in the first place, and still want obviously, is for these to be defined, so I don't have to explicitly typedef myself pre-defined Ant role impls in my build script. If somehow we go your proposed put-them-all-as-types route, then I also won't have to typedef them explicitly, which I like, but we haven't resolved the name conflicts at all. And your proposed clever solution to this is not an acceptable solution to me (at this point). The ideal solution would be in fact to allow registering several classes/types under the same name, and the Ant runtime to pick the one type for which isA(Type) is true, fort the Type at hand, failing with an Ambiguous error if more that one such type exists. This way, you could register AndSelector and AndCondition with <and>, and use the 1st in the context of add(FileSelector), and the 2nd when with an add(Condition). This doesn't eliminate all conflicts, as for example your ContainerConditionOrSelect has both, it would be Ambiguous still. To me, using role-specific AntLibs is simply the only foul proof solution to name conflicts, that fits the existing behavior of Ant. --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
