From ant-dev-return-13592-apmail-jakarta-ant-dev-archive=jakarta.apache.org@jakarta.apache.org Wed May 09 14:42:26 2001 Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org Received: (qmail 69892 invoked by uid 500); 9 May 2001 14:41:48 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk Reply-To: ant-dev@jakarta.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 69825 invoked from network); 9 May 2001 14:41:32 -0000 Message-ID: <011201c0d896$a82e6240$1ec7223f@cognetnt> From: "Conor MacNeill" To: References: <3.0.6.32.20010508225535.01e2a730@mail.alphalink.com.au> <3.0.6.32.20010509154017.00b03d90@mail.alphalink.com.au> Subject: Re: [Vote] Avalon-Framework integration Date: Thu, 10 May 2001 00:44:25 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Pete, From: "Peter Donald" > >"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