ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: Proposed Revolution: AntEater (a proposal for Ant Core 2.0)
Date Tue, 14 Nov 2000 14:49:50 GMT
At 06:41  14/11/00 -0800, you wrote:
>Only one of several arguments I'm trying to make, and
>I don't think the "cleaner core" argument has been
>strongly posed. 

I am very strongly +1 for cleaness at all times - you can read the archives
to see what I mean ;)

>I certainly can be swayed by this
>argument (even at the expense of having to write a lot
>more code), but I'd like to hear how having Project,
>Task, Target, etc. implement the Element interface
>results in an ugly or burdensome API (especially if
>they implement it via inheritence from a AntBaseNode
>class or something similar).

Software Engineering 101 - Have the simplest possible interface that can
represent what you need. 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 @ www.jdom.org 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.

>I hope I'm not coming across as being rabid on this
>issue; I just want to make sure that the benefits are
>understood from a long term perspective. 

Be as rabid as you want as it will ensure that we get a better ANt ;)

>That being
>said, if the Ant data model ends up /not/ being DOM
>compliant, I will probably have to mirror the data
>model in order to preserve the ability to marshal and
>unmarshal (if you will) the build.xml file in a way
>that preserves comments and Text nodes. 

Well - I am not so sure with text nodes except whitespace and whitespace
should be able to be ignored in build files. For comment nodes then I agree
you will probably have to write your stuff to keep them about. However
depending on the architecture that .duncan proposes we may be able to hack
it in by extending core.

>But then
>again, I'm open hearing how this might be done in
>another elegant fashion. 

Well have a look at JDOM (www.jdom.org) and Configuration interface in
Avalon project (java.apache.org/framework). 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 just think it would be
>really simple to have an AntBaseNode class that
>implements the Element interface, from which the
>Project, Target, etc. classes inherit, to take care of
>all this.

Seems like added complexity with little benefit.

> The users of these Ant classes needn't even
>know about all the DOM related methods if they don't
>want to. 

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.


Cheers,

Pete

*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |
*------------------------------------------------------*

Mime
View raw message