ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <co...@cortexebusiness.com.au>
Subject Re: [Vote] Avalon-Framework integration
Date Wed, 09 May 2001 14:44:25 GMT
Pete,

From: "Peter Donald" <donaldp@apache.org>
> >"Compression in OO languages is created when the definition of a
subclass
> >bases a great deal of its meaning on the definitions of its superclass".
>
> exactly the thing Avalon was designed to avoid actually ;)
>
> Because we all know OO failed except in particular domains (ie GUIs)
> Avalons framework is designed for this exact use case. The solution to
> compression is usually sited as Component Based Programming + Aspect
> orientated programming.
>
> Component methodologies assume that there is low depth of inheritance.
Some
> methodologies (thinking of MSes definition of components) even go to
> lengths to guarentee that there is only one level of inheritance. Avalon
> does the same.

Huh?  Can you then please explain to me why on
http://jakarta.apache.org/avalon/framework/reuse-standards.html, one of the
twleve rules of reuse (what frameworks promote) includes (and I assume this
includes Avalon)
"Class Heirarchies Should be Deep and Narrow"

> As I said documentation will soon be fixed so that is a non issue.

But it is an issue. We are designing Ant2 now. You especially are pushing
on this. How can we base that on something that is undocumented when
excellent documentation is seen as one of the fundamental requirements for
being able to effectively use a framework. I don't see how people not
involved in Avalon can effectively contribute.

> As I
> have also stated if the users extend AbstractTask (or
> AbstractContainerTask) they will not have to know that they are even
using
> Avalon ;)

or that they are not using Avalon :-)

>
> fixed in Avalon - it was always a temporary hack to get proposal out.
>  ...
> they were hacks to get around a change in Avalon that I wanted
> reintegrated. Avalon/Framework has had these changes integrated and we
can
> throw them all away except for Configurers.
> ...
> Yep - mainly as proposal was just bare bones I banged it out fast - the
> real method would have a lot more encapsulation (especially
AbstractTask*)
>

So the example usage of Avalon to which you referred people, you now
dismiss as quick hacks. Fair enough but then I have less to go on to
evaluate how Avalon would be used and how it would be useful. My impression
from myrmidon was that it leads to overabstraction, compression and lower
readability.

>
> >For me, Ant is a pretty fundamental component which should have minimal
> >dependencies on other projects.
>
> We will end up recreating the same things again in Ant that exist in
Avalon
> - except they will be raw and untested.

And how have they been tested in Avalon? You just stated above that "Well
considering that Framework has been designed around Ant as a use case this
won't be an issue for us". Considering the usage of Ant, I think it will
get a fair amount of testing. Natural open source effect.

>
> Is there any answers that you aren't satisfied - or does your -1 still
> stand - and if so why ?

Pete, it is just not that easy. My -1 still holds. In fact, I believe if
another committer states that my veto is valid, it cannot be downgraded.
Anyway, your statements that you just quickly hacked stuff up seems to say
to me that the framework is not that mature. Is that the case?

I have other concerns. When you build code with a framework, it is like
building a chair with two legs. It only works when the framework supplies
the other two legs. If you want to take that code somewhere else, the
framework has to come along. That isn't always appropriate.

>
> BTW: If you think *this* is controvertial you should wait to see what I
> have to say in future ;)
>

No worries, I'll have my -1s ready.

Conor



Mime
View raw message