My $.02... Day 3: Yes! Day 4: No (on removing Configurable)! I like having the stricter interface definition and less type-casting. Day 5: No!!! I like the ServiceManager (and ServiceManager.release) Day 6: No? I've thought about this before, but I like the LogEnabled interface for convenience reasons. Day 7: No. I like my no-arg constructor (again, convenience).
I don't think we should be thinking simply in terms of what a component needs "bare-minimum", but perhaps the bare-minimum of what a simple-to-implement (and well defined) component needs. I would actually make one suggestion. Where the story suggests removing the ServiceManager in favor of the Context, I would propose the opposite. The Context is indeed the most abstract interface in the Avalon framework, but I think that is a weakness, not a strength. The ServiceManager is used to locate services adhering to a particular interface. The Context, uh, ... Well, the Context.... umm. What the hell is the Context? Any component that uses the Context is tied too tightly to a particular container (IMHO). Jonathan Hawkes ----- Original Message ----- From: "Stephen McConnell" <[EMAIL PROTECTED]> To: "Avalon Developers List" <[EMAIL PROTECTED]> Sent: Friday, November 14, 2003 7:50 AM Subject: Re: shameless plug: articles on COP, other stuff > > Here are things that I like: > > 1. the story > > Heres the thing I think are valid points: > > 1. the collapse of parameters and configuration (day 3) > 2. the collapse of service and context (day 5) > 3. the principal of context by constructor (day 7) > > And the thing I'm not convinced about: > > 1. merging config into context (day 4) > 2. disolving logging (day 6) > 3. the principal of context by constructor (day 7) > 4. the tideiness of Leo's room > > Cheers, Steve. > > > > Ulrich Mayring wrote: > > > Stephen McConnell wrote: > > > >> > >> I like this page: > >> http://lsd.student.utwente.nl/jicarilla/StoryOfThe6LifecycleMethods > > > > > > I don't. > > > > The idea of the lifecycle methods is that they are called from outside > > at various points in their lifetime. Constructors can only be called > > once, so it seems not very useful to put the lifecycle methods in a > > constructor. > > > > Also, the detailed strategy reminds me of my childhood: > > > > Mother: You've got to clean up that mess you call your room! > > > > Ulrich: Ok, I'll do that... *shuffle, shuffle, shuffle* ... DONE!!! > > > > Mother: Well, it looks neat now. But you just took everything and > > shoved it under the bed. > > > > Ulrich: Yeah, that's called refactoring. > > > > > > cheers, > > > > Ulrich (who grew up a bit since then ;-) > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > > Stephen J. McConnell > mailto:[EMAIL PROTECTED] > > |------------------------------------------------| > | Magic by Merlin | > | Production by Avalon | > | | > | http://avalon.apache.org/merlin | > | http://dpml.net/ | > |------------------------------------------------| > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
