> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] > > > 2) The Parameters object is either a synonym for the Configuration > > object or we must EXPLICITLY define WHERE in the H-E-double hocky > > sticks it comes from. Unequivocably. > > I never assumed it was a synonym for the Configuration object. > > > The Parameters object must have a predictable content, and > that cannot > > be the case if one container does one thing and another container > > disregards those contracts. > > I don't understand. The contract is to give a Parameters object, as > Configuration does to Configurable objects. > > I don't see that Configurable comes with a specification on > how to get a > Configuration, hence I don't think it's needed for Parameters.
And the purpose of parameters is a simplified configuration, so the assumption (perhaps bad, but nevertheless common) is that it originates with the configuration. As we can see assumptions are the anti-pattern of contracts :) > >>There is no reason why having both is bad. > > > > > > Maintenance. If your component is configured in two > different ways, > > the poor person coming in after you to clean up your mess > (uh, err, I > > mean add new functionality) has to go through more than one > method to > > see what gets set where. > > > > We want to reduce the work of the maintainer--making Avalon > harder to > > resist. > > Hard not to agree with this ;-) > > <typical-nicola-ken-involute-thought > please="read the general meaning, not the details"> > It seems that you are more focused on excalibur stuff that > the Avalon framework, which is more generic. This is typical > of everyone I assume, because we tend to see > APIs+Reference implementations (I could be wrong). > </typical-nicola-ken-involute-thought> There is probably some truth to that. Our perceptions of the framework are influenced by the implementations that we have worked with. The important thing is to identify lapses in stated contracts and determine if they are something we want to enforce. > You say that if we want to keep the two, they must have a clearly > specified role, and it should be *different*, or else the programmer > "has to go through more than one method to see what gets set where." > > Ok, then in this case I would deprecate the Parametrizable > interface and > put a Configuration.getParameters(), that returns flattened > parameters > ala Ant > (see the XMLProperty task I submitted to Ant > http://jakarta.apache.org/ant/manual/CoreTasks/xmlproperty.html) > > :-) > > <myconf> > <hey>hi</hey> > <do what="it"/> > <a> > <b> > <c d="e"/> > </b> > </a> > </myconf> > > becomes: > > hey=hi > do.what=it > a.b.c.d=e > > Anyone sees a specific need for Parametrizable that cannot be > done or is > not feasable with Configurable? I believe that they are essentially the same, but their representation of data is different. BTW, the default configuration mapping to parameters mapping is: <config> <parameter name="hey" value="hi"/> <parameter name="do.what" value="it"/> <parameter name="a.b.c.d" value="e"/> </config> yielding the same results as above. We don't want to lose this. So the question is, do we need Parameterizable? If not, then the Parameters object needs to be placed into the Configuration package, and have the parameters easily derived from the configuration. The backwards compatibility layer will take the configuration object and send in the Parameters.fromConfiguration(config) call to get the parameters object. That way the wrapper for A4 components continue to function as they should--and we have one way of configuring A5 components. I think this will aleviate a lot of confusion, and make it easier to maintain A5 components. Thoughts? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
