Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 92155 invoked from network); 4 Jul 2002 07:51:59 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 4 Jul 2002 07:51:59 -0000 Received: (qmail 26633 invoked by uid 97); 4 Jul 2002 07:52:19 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 26575 invoked by uid 97); 4 Jul 2002 07:52:18 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 26563 invoked by uid 98); 4 Jul 2002 07:52:18 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <3D23FE81.5060505@apache.org> Date: Thu, 04 Jul 2002 09:51:29 +0200 From: Nicola Ken Barozzi Reply-To: nicolaken@apache.org Organization: Apache Software Foundation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avalon Developers List Subject: Re: tweety 1.0.1-alpha is available References: <1025728507.6214.32.camel@lsd.bdv51> <3D2364CE.2070600@apache.org> <1025768072.1966.19.camel@lsd.bdv51> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Leo Simons wrote: >>Leo Simons wrote: >> >>>all, >>> >>>tweety is ready to go online. Dist are at >>> >>>http://cvs.apache.org/~leosimons/excalibur/tweety/ >> >>cool :-) >> >>Leo, I still think that having made the main class a Component itself >>with the lifecycle methods is confusing for early users, as well as the >>fact that main() makes it call them on itself :-S > > > hmm. having main() instantiate a copy of itself is, I think, quite > common behaviour. Which I don't like much. > The alternative is to have another class, called Main, > that instantiates Tweety. Wonder what is clearer. IMO the second. >>I would just revert to the old behaviour which is more simple, and >>thought you kinda agreed on this... >> >>What do you think? > > Like I said earlier (I think), not making Tweety a component would be an > example of bad design. If you just use tweety, you just type 'ant run' > and never deal with anything of its internals, so the *exposed* > behaviour is exactly the same. If you want to look at the source to > Tweety to learn what it does, I think it is very important that the > source is well-written according to our own standards. Less is more. If we want to explain how Container-Component works, we should make a Container and Components, not A Container that is a Component and a Component. Making everything a Component has lead to the misuse we have in Cocoon, and this only encourages it. > And the less pronounced motive is that I'm sure people will be misusing > Tweety, for example putting it inside phoenix or somethin'. While I > 'officially' disprove, I can see why =) Hey, this is why I *don't* want Tweety itself to be a Component. If it is, as now, users *will* ignore main and use it as a Component. Sorry, but I don't understand Leo, it seems confusing to me what you say. I want Tweety *not* to have lifecycle methods. Lifecycle methods help in IoC, but if it calls them on himself it's a very bad programming example. There is no inversion, no clear Container-Component separation. -- Nicola Ken Barozzi nicolaken@apache.org - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- -- To unsubscribe, e-mail: For additional commands, e-mail: