Emmanuel Bourg schrieb:
+1 for removing the old configurations, otherwise that would be
confusing for the users.
Regarding the package structure do you have other plans besides the
'flat' package ?
I would like to keep main package pretty small, so that it only contains
the basic interfaces and abstract base classes.
Sub packages would group classes with similar functionality. The plist
and web packages are good examples for that, but I am not sure how to
handle specific implementations consisting of only one or two classes
(e.g. INIConfiguration). Putting them in their own package probably does
not make too much sense.
Oliver
Emmanuel Bourg
Agreed. After refactoring of the hierarchical file-based configurations
is complete, it shows that the new configurations are indeed a full
replacement for the old ones: all unit tests are still running.
About the naming: If all our configurations are hierarchical (at least
this is the plan currently), there does not seem to be much point in
calling a concrete implementation "HierarchicalConfiguration". Therefore
I used the name "InMemoryConfiguration" for the replacement (because the
whole data is stored as ConfigurationNode objects in memory).
In the first discussions about the new configuration2 branch somebody
suggested using a different package structure, which is more focused on
modularity, i.e. there should be packages containing configuration
implementations with a specific functionality. I would like to follow
this suggestion. Any objections or further comments?
Oliver
---------------------------------------------------------------------
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]
