Berin Loritsch wrote:
>>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.
+1 I was +0 because it sounded good, but now I also see it in practice :-)
>>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?
I don't do it this way.
This is how Cocoon does it AFAIK, take off your Cocoon hat ;-)
>>- there is no reason why they have to be mutually exclusive
>
>
> There is no reason why the shouldn't be....
;-)
In this case, the most lazziefaire wins (not exclusive).
Every imposition you put is something to check for, ergo more complexity.
If it's not that important, let's not enforce it.
>>- 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.
See above.
>>- 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
Directions?
What directions?
> Sure there is--but it has to be clearly stated in the javadocs,
> and in any exceptions or log messages thrown by the container.
Naaa, good systems must be self-commenting and self-enforcing.
Easy does it.
>>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.
The fact that there is no distinction is good.
Gives more flexibility, makes no harm.
> Also the parameters object is derived from the configuration object
Not here, that's a Cocoon implementation detail.
> that would otherwise be passed into the component. Really, it is
> pretty messy to mix those two.
Still don't see why.
One thing is *recommending* to use one or the other.
Another is *enforcing* it.
There is no reason why having both is bad.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
