> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] > > Berin Loritsch wrote: > > I see nothing wrong about the Parameters package as a general rule, > > just a couple questions: > > > > 1) Do we want to decouple the Parameters interface from the > Parameters > > object > > like we do with Configuration? > > > > 2) Are we going to explicitly declare Parameterizable and > Configurable > > as > > mutually exclusive? > > > > As to #1, it would provide consistency and provide a nice way of > > making different implementations of the parameters object. > It would > > also encourage us to place the Parameters.fromProperties() and > > Parameters.fromConfiguration() > > methods into a ParameterUtils class. > > +0, but we must keep some compatibility with the past.
I am not proposing we change the interface completely, but move the static methods to another utility class. The compatibility layer will hide these changes from existing systems. The framework-compat.jar should provide binary compatibility as much as possible. This is one case we can guarantee it--and provide a cleaner design at the same time. > I'm against making them mutually exclusive: > > - users use them together The common implementation between Parameterizable and Configurable is this: component.configure( config ); component.parameterize( Parameters.fromConfiguration( config ) ); What's the big deal about doing that in your configuration method? > - there is no reason why they have to be mutually exclusive There is no reason why the shouldn't be.... > - there is no way to enforce it There is through helper classes. Those classes would be available in framework for containers to use to validate the lifecycle. > - there is no way to make users easily understand this You're the kind of person who throws the directions away before you start to put a bike together aren't you? ;P Sure there is--but it has to be clearly stated in the javadocs, and in any exceptions or log messages thrown by the container. > I use Configuration for general config, and Parameters for > per-instance > config, even in the same class, and find it usefull. In avalon framework there is no distinction between general and per-instance configuration. Each instance of the component is fed the same configuration object or parameters obect. Also the parameters object is derived from the configuration object that would otherwise be passed into the component. Really, it is pretty messy to mix those two. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
