ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: Scope of Types
Date Fri, 01 Jun 2001 17:32:32 GMT
> From: Peter Donald []
> At 11:44 AM 6/1/01 +0100, Jose Alberto Fernandez wrote:
> >> From: Stefan Bodewig []
> >>
> >> > Flat is theoretically the best example because all
> definitions are
> >> > local.  However I guess I am worried about usability.
> >>
> >> What if you'd allow to import types from a nested
> namespace into the
> >> default namespace? Something that is what you call flat
> with a little
> >> bit of global added to it?
> >>
> >
> >We could have something like:
> >
> >	<projectref name="mod" ... />
> >	<taskdef name="blah" aliasfor="mod->foobar" />
> >or
> >	<import name="libblah" lib="mod->modlib" />
> >
> >I do not think we can just use them without redeclaration,
> unless we use a
> >different namespace operator:
> >
> >	<mod->foobar  ..... />  <!-- This is illegal syntax -->
> >	<mod:foobar .... />     <!-- I think this is fine XML -->
> >
> >comments?
> Personally I get kinda scared when there is talk of sharing type defs
> between projects in this manner. Where do you see it as
> useful? I can see
> it as useful when propogated via antcalls (ie
> subordinate/child projects)
> but become concerned when peer projects (via projectref) are
> using it.

The question for me is how reusable do we want the information in the "peer"
projects to be. In one extreme, if we want it to behave like "include" (not
that I am advocating anything) it will require for the including project to
have access to anything available in the included project. Because it is
like a macro expansion.

Now, we are not doing "imports" exactly (thank God) so the rules are more

What we habe been talking is that <projectref> loads an instantiation of the
project (given the <param>s passed in the declaration). You can access
anything in the namesapace, any properties AND any IDed type instances. If
you can access the instantiated values of a type, then it seems to be a
logical consequence that you may need to have access to the type itself.

For <tasks> one may have a simillar argument. If you have access to the
targets in the instantiated project, you may also want to have access to the
tasks defined in there.
For example a projectref may define a group of libraries that are used for
performing its work. The tasks may be interdependent in the sense of
compatibility between version or what have you.

I would think, one may want all this things said in just one place, for
maintainability reasons. The referring projects will just use the consistent
by just indirecting on the projectref namespace.

> Personally I would prefer namespace resolution for types (and
> aspects) to
> be static "type" information rather than dynamic "instance"
> information. So
> namespace of type would refer to the library it was exported
> from (or a
> user assigned value).

But if you look at <projectref> as static. It is not a task, it is simillar
to <taskdef> but for projects. I know that there is certain dynamic behavior
for <taskdef> and such, but in principle it is defining a static thing that
cannot once defined.

> Can anyone give a good usecase forsharing type defs between
> peer projects?

Does anyone has a good example on when one may need a new type definition?
The predefined ones have been sufficient for me. I would need something like
that first, to be able to come up with an example. ;-)

Jose Alberto

View raw message