On Thu, 19 Dec 2002 04:08 pm, Peter Donald wrote: > On Thu, 19 Dec 2002 13:19, Adam Murdoch wrote: > > - A Logger is delivered by LogEnabled.enableLogging(), and is the first > > lifecycle method called. > > - A Context is delivered by Contextualizable.contextualize(), and is the > > second lifecycle method called. > > - A ServiceManager is delivered by Serviceable.service(), and is the > > third lifecycle method called. > > - Configuration is delivered by Configurable.configure(), and is the > > fourth lifecycle method called. > > - Parameters are delivered by Parameterizable.parameterize(), and is the > > fifth lifecycle method called. > > Parameterizable occurs at same time as Configurable and is incompatible > with Configurable.
Perfect! This is an even better example of the mess of contracts that a component developer has to keep track of. And since we're doing the pedantry thing, let's chuck in Composable, which is incompatible with Serviceable. And the contract where you're allowed to cast Context to a container specific interface too. Goodness. I just want to get the stuff I need for my component. Why is it so hard? Why do I need to know all this stuff? Why isn't there a single method that gives me what I need? What benefit do I get out of all these methods and contracts? As an aside, if you look at containerkit.LifecycleHelper, you'll see that it allows a component to implement both Configurable and Parameterizable (it's where I got my list of contracts, above, from). And BlockResourceProvider will happily produce both Configuration and Parameters for the same component. Is this intentional? > > There are orders of magnitude more components than there are containers. > > Let's figure out how to make it as easy as possible to write a component. > > Once that's sorted, then we can start compromising framework for the sake > > of the container writers. Let's not do this prematurely. > > There is as many different styles of component writers as ... ? > > Why is this a problem? Why can't it be addressed in meta-info *if* it > > becomes an issue? We're already looking at meta-info that describes what > > a component expects to be exposed via ServiceManager and Context. > > Argueably the same will happen for config and params (if not in > > meta-info, then meta-data). > > already done. In Phoenix, yes? It's a pity there isn't something at the framework level. > > This is SoC. > > ... > > > To put fragmentation of concerns more concretely: > > SOC/FOC are one and the same. Not so sure (see Berin's reply). But let's not bother with terminology. Whatever you happen to call this antipattern, taking a single real concern and dividing it into several artifical concerns causes problems. Some of the warning signs: Extra work for the (real) concern's user, complex dependencies between the 'concerns', difficulty assigning meaning to all of the 'concerns'. Avalon suffers from all of these. Granted, these problems aren't exclusive to over-fine concern separation, but are good indicators. Let's figure out what's wrong. -- Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
