ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simeon Fitch <>
Subject Re: Proposed Revolution: AntEater (a proposal for Ant Core 2.0)
Date Tue, 14 Nov 2000 15:40:28 GMT
--- Peter Donald <> wrote:
> At 06:41  14/11/00 -0800, you wrote:
> Software Engineering 101 - Have the simplest
> possible interface that can
> represent what you need. 

But Professor, what about leveraging existing
standards and frameworks? ;-)

> DOMs element is very
> complex, slow and bloated. It
> was designed with the idea of cross language support
> etc and in reality was
> a failure - see JDOM @ who redid DOM in
> a java way. 
> Now do we need the functionality provided by Element
> interface ? I would
> say no to about 80% of it - and thus it is not
> really a good idea to create
> 80% new interface methods that will not be widely
> used.

The JDOM stuff looks very nice, and I think I
understand where you are coming from with your
argument. I admit that my proposal for extending
org.w3c.dom.Element is only *one* option, and after
thinking about what you said probably not the best
one. I think I've so far been swayed by the idea of
using the Element interface because there are other
tools out there that know how to speak "w3c DOM", if
you will. I love to be able to leverage other's work,
but in our case the so called "bloatedness" of the w3c
framework may be too much.

Since you pointed out that I've forgotten what I was
taught in Software Engineering 101, I should admit
that I forgot my SE 102 lessons as well; in my
arguments I made the mistake of focusing on
implementation rather than requirements. So let me
step back and list the requirements I hope to have

1) A navigatable tree structure that is faithful to
the XML file structure.
2) A common base class (other than Object) that the
tree nodes inherit from for those cases where
generality can be represented and common behavior
gathered (like an abstract write() method and generic
getParent() and getChildren() methods).
3) The ability to reconstruct the XML input, including
comments, by appropriate traversal of the tree.
4) (The most GUI specific, but also useful for
scripting) The ability to register
PropertyChangeListener instances with the nodes to be
informed of property changes.

> Well have a look at JDOM ( and

Much nicer than w3c DOM!

> Configuration interface in
> Avalon project (

Can you give me a package name? I briefly search
through the CVSWeb and only ran into a configuration
package with everything in the Attic. I'm very
interested in learning more.

> Configuration elements are a
> 1-to-1 mapping with what Ant currently uses - JDOM
> is a drastically
> simplified DOM model that is performance sensitive
> ;)

I'm certainly interested in learning more from the
lessons that Avalon has to offer. I'm sure duncan
already has his ideas on how he wants to do things,
but do you have some proposals you can make on how to
meet the desires for a common data model?

> But they may - and then when other people read their
> tasks it will be
> difficult decipher (near impossible in some cases)
> and it adds a lot of
> extra bulk that is not needed IMHO.

Not to kill a dead horse, but if tree traversal
semantics are tucked away in in a base class above, then those people extending can
focus on the methods that it provides and requires for
implementation. It's kinda like the thread support
that's stuffed into the java.lang.Object class; you
never think about the fact that it is there unless you
are working with threads. Though I concede that there
are many other options that use of the w3c interfaces
for the data model, I think your case here about
complexity is overstated.

Thanks for the good dialog tho!


Mustard Seed Software

Do You Yahoo!?
Yahoo! Calendar - Get organized for the holidays!

View raw message