ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: [myrmidon] Type Librarys
Date Wed, 08 May 2002 09:43:59 GMT
On Mon, 6 May 2002 22:53, Darrell DeBoer wrote:
> On Mon, 6 May 2002 20:30, Peter Donald wrote:
> > Hi,
> >
> > I just went and updated some of my older tasks to latest stuff you are
> > doing with Librarys. Anyways before I got too far with that I was
> > wondering where exactly you are going with the library stuff. Have you
> > got a grand unified plan and if so want to xml-ize it and add it to our
> > xdocs :)
>
> Hi Pete,
>
> Not exactly what you're asking, but I've been playing around with something
> related, which I think will prove quite powerful.

excellent.

> The idea is to provide a namespace mechanism for type names, so that
> multiple types with the same name can coexist. The idea runs as follows:

woohoo!

> 1) Types/TypeLibs can be registered under a namespace, which *may* be taken
> from the AntlibDescriptor (say, an AntLib name attribute), but can also be
> specified in other ways (eg <typelib library="ant1compat"
> namespace="ant1"/>)

I would prefer it to be based on the name of the antlib (ie internal name 
specified in manifest). I suppose we could support aliasing but I would like 
the importing to be very obvious that it is aliasing that is occuring. Maybe 
something like

<typelib library="ant1compat" namespace-alias="ant1"/>

> 2) As works currently, Type name resolution occurs by first looking in the
> local context, and then up through the parent contexts.

yep. 

Same as propertys, and resources and anything else we add?

> 3) When a TypeFactory is requested from the TypeManager, the name used can
> be fully qualified (has a namespace), or not. A fully-qualified name
> requests a named type registered under a particular namespace, whereas an
> unqualified name involves searching all namespaces for the type name. If
> the name cannot be resolved unambiguously within the context, an error
> occurs.

Sounds good. Basically this is the same way as imports are handled in java 
yes?

> 4) The core antlibs (ant/lib/*) will be registered under an antlib name, 

+1

> 4a) Perhaps types explicitly type-def'd (not an entire library, a single
> type), would be considered higher precedence again, above <import>ed
> library types.

+1

> 5) I'm also thinking about separating the TypeManager interface into a
> superinterface (TypeRegistry?) with just the lookup methods, together with

+1 (Matches how Converter evolved).

> Question:
> Is it appropriate to use XML namespaces for ant type namespaces? 

It has been -1'ed before due to complexity and extra cruft that it adds. We 
could still use ":" as separator but type resolution should follow the java 
import tules which I believe what you propose does ;) However I would prefer 
"."

> (And if not, are we planning to utilise XML namespaces for anything?).

At one stage I played with idea of basing "aspects" on namespaces but that 
turned out to be too complex an idea and most of its benefits can be got by 
simpler/better mechanisms (ie use ContainerTasks rather than aspects). 
Considering aspects are largely axed atm I am not sure I can see it be using 
at all ... 

-- 
Cheers,

Peter Donald


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message