ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Devienne" <DDevie...@lgc.com>
Subject RE: Ant "roles"
Date Fri, 15 Apr 2005 19:19:23 GMT
> From: Peter Reilly [mailto:peterreilly@apache.org]
> 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message