commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Moore" <tmo...@blackboard.com>
Subject RE: The exegesis
Date Mon, 12 Aug 2002 20:30:41 GMT
> > Niclola wrote:
> > There is NO TECHNICAL NEED of having interfaces like these.
> 
> Actually thats half the point. No, I'm not mad! And maybe its 
> just a different programming style to yours. My argument is 
> that Initializable in [pattern] has no baggage, no 
> implications, no significance, nothing.

Then what's the point of having it?

-- 
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863


> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com] 
> Sent: Monday, August 12, 2002 4:06 PM
> To: Jakarta Commons Developers List; nicolaken@apache.org
> Subject: Re: The exegesis
> 
> 
> Nicola, (Berin),
> A little while back you suggested that I might help clarify 
> the boundaries between Avalon and Commons. Well I have, but 
> maybe only in my own mind...
> 
> I think there is pretty much agreement on the following:
> - Avalon defines component lifecycle interfaces
> - Commons should not define component lifecycle interfaces
> 
> The key word is 'component'.
> 
> Javadoc for 'Initializable' from Avalon:
> "Initialialize the component. Initialization includes 
> allocating any resources required throughout the components 
> lifecycle."
> 
> Javadoc for Avalon framework package:
> "The Framework part of Avalon contains interfaces and 
> contracts surrounding those interfaces, along with default 
> implementations of some of those interfaces. Among other 
> things, these interfaces impose a COP development model. "
> 
> These two pieces of javadoc, IMO, explain why Avalon is good, 
> but also why lots of people don't use it. Avalon is about a 
> COP development model. Its interfaces help define that. But 
> there is also documentation and other best-practice that goes 
> beyond actual Java code. That's great. But none of that has 
> anything to do with commons. And is why commons will never 
> depend on Avalon.
> 
> 
> What I would like to do with [pattern] is define common 
> method signatures. These can be used by _any_ object, not 
> just by components. They do not specify an order. They do not 
> require a container. They are, in essence, meaningless (as 
> opposed to Avalon, where each interface has great meaning). 
> This is the great leap of faith for an Avaloner like 
> yourself. Can you accept that a method signature, such as 
> initialize(), can standalone?
> 
> > Niclola wrote:
> > There is NO TECHNICAL NEED of having interfaces like these.
> 
> Actually thats half the point. No, I'm not mad! And maybe its 
> just a different programming style to yours. My argument is 
> that Initializable in [pattern] has no baggage, no 
> implications, no significance, nothing. Its just a suggestion 
> for a method name. On the other hand, Initializable in Avalon 
> requires COP, and thus associated issues.
> 
> Initializable in Avalon is thus a specialism of the generic 
> Initializable in [pattern]. But a specialism that adds COP 
> semantic meaning. It gives you no technical benefits (well 
> virtually none - there would probably be a Command adaptor in 
> [pattern]).
> 
> (BTW, I'm a realist. I don't actually expect Avalon to 
> suddenly go out and change its interfaces to extend [pattern]. Yet.)
> 
> 
> My idea of [pattern], outlined above, is radical. And so is 
> the relationship to Avalon.
> 
> Stephen
> 
> BTW: Ask yourself why [pattern] can have Resetable, but not 
> Initializable?? There's no difference.
> 
> 
> From: "Nicola Ken Barozzi" <nicolaken@apache.org>
> > Stephen Colebourne wrote:
> > > From: "Geir Magnusson Jr." <geirm@adeptra.com>
> > >>On 8/11/02 6:26 PM, "Vincent Massol" <vmassol@octo.com> wrote:
> > >>
> > >>
> > >>>I haven't been following the discussion, but I agree with you : 
> > >>>Avalon Framework should be in Commons
> > >>
> > >>I haven't followed either, but just explain the above - why should
> Avalon
> > >>Framework be in commons?  Do the avalon people want it in 
> commons?  
> > >>Why don't they want it in Avalon?
> > >
> > >
> > > The views seem to be (generalising):
> > > - Avalon people want lifecycle in Avalon
> >
> > Avalon folks *HAVE* lifecycle in Avalon.
> > Before Commons came along, Avalon *was* the Java Apache Commons.
> >
> > > - Many commons people instantly -1 the moment 'lifecycle' is 
> > > mentioned
> > > - I have said that lifecycle type interfaces COULD go in [pattern]
> > >
> > > There is a degree of confusion however. Lifecycle to an Avalon 
> > > person
> means
> > > a particular set of interfaces that mean VERY precisely defined 
> > > things
> in a
> > > contract that works ACROSS interfaces. When I talk about putting
> lifecycle
> > > type interfaces in [pattern] I mean interfaces that are 
> INDEPENDENT 
> > > of
> one
> > > another, not part of a framework.
> > >
> > > Is there really something scary about saying that if a 
> class can be 
> > > initialised then the method name should be initialize()?? As a
> standalone
> > > interface?
> >
> > Useless and confusing.
> > There is NO TECHNICAL NEED of having interfaces like these.
> >
> > > What if the lifecycle type interfaces were in [pattern] ??  The 
> > > Avalon interfaces still exist - they extend the Commons 
> version not 
> > > to add
> extra
> > > methods, but to add the cross-interface lifecycle 
> contract that is 
> > > at
> the
> > > heart of Avalon.
> > >
> > > Re-read that last paragraph. Then read it again.
> >
> > You read it, and try to understand.
> >
> > Why the heck should we extend the Commons version?!?!
> > Tell me a TECHNICAL need. A REAL one though.
> >
> > > If you understood it then everyone should be happy.
> > > - Lifecycle, as a framework, is in Avalon.
> > > - Lifecycle pattern interfaces are in [pattern].
> >
> > Gee, if you need them, go ahead and do them, but you will 
> keep getting 
> > -1s from me and probably the rest of the world.
> >
> > You need those interfaces.
> >
> > USE THEM! THEY ARE IN AVALON! >:-//
> >
> > --
> > Nicola Ken Barozzi                   nicolaken@apache.org
> >              - verba volant, scripta manent -
> >     (discussions get forgotten, just code remains)
> > 
> ---------------------------------------------------------------------
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
> >
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> 
> 

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message