ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Roles (was: antlib)
Date Tue, 29 Apr 2003 12:12:54 GMT
On Mon, 28 Apr 2003, Costin Manolache <> wrote:

> If ParentClass has no addMyChild()/createMyChild() method, we'll
> need to look up in some table and find a class associated with
> <myChild>.

OK, well, maybe, see below for an alterbative view.

> We'll then look in ParentClass for an add method with that
> particular interface as parameter.

The use-case is too simple as the ParentClass could have more than one
method with that interface (or even different interfaces implemented
by the class mapping to myChild).

> - should we add a separate table for <child>->class association - or
> just use the typedef ?

A single table.

> - Should we use (<parent>, <child>) tuple to find the class? Should
> we use (ParentClass, <parent>, <child>) tuple ?

I'm not sure what the difference is, here.

> Or just <child> name - i.e.  context-free ?

No, would already break down today.

> - addComponent( MyRole ) or addMyRole( MyRole ) or both ?

I assume you are taking MyRole as the name of the interface here, as
I'm not convinced that we need formal roles at all.

> I.e. a fixed-name method, with overloading to support multiple
> roles, or one add method per role ?

Neither is enough IMHO.

> - should setComponent be used to indicate single-child ?

No.  Let's keep set* for Attributes.

> ( of course, all primitives that can be used as attributes will
> remain attributes )

Path can already be used as Attribute and as nested element.

Let's take DependSet as an example.  It has two kinds of nested
FileSets, srcfileset and destfileset.  For the sake of discussion lets
assume that placing ClassFileSet or ZipFileSet for either "kind" of
FileSet was useful - I think it is at least for ZipFileSet.

<dependset ...>
  <zipfileset src=""/>

with the approach you describe, 

If we follow the "name determines implementation" route you've
described here, both addSrcfileset(FileSet) and
addDestfileset(FileSet) would be candidates for methods to call.  We
need a way to resolve this - probably via an extra attribute that
explicitly says "I'm a srcfileset".  Something like

<dependset ...>
  <zipfileset src="" element="srcfileset"/>

The alternative approach (taken by Mutant IIRC) would look like this

  <srcfileset src="" type="zipfileset"/>

Here the approach is to look up the expected interface by the method

I feel this second approach is easier in the (rare?) cases where
things are ambiguous, but it also forces people to always explicitly
state the type.  I'm not sure that the later is a drawback, though.

With this approach the parent completely determines which element
names are supported as nested elements and at the same time clearly
states which interface is expected from the child element.

This makes documenting stuff a lot easier.  Imagine the nested
elements of copy.  <copy> accepts nested <fileset>s or any element
whose name maps to a class that extends

I think the learning curve for beginners to grok

<copy ...>
  <classfileset .../>
  <zipfileset .../>

is steeper than the alternative

<copy ...>
  <fileset type="classfileset" .../>
  <fileset type="zipfileset" .../>

I'm not really sure myself, I've argued the first approach myself when
we discussed it the last time around (because the non-ambiguos case
requires less typing 8-)


View raw message