From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-04-23 16:19:39
When I my review I never thought it will cause any long discussion. It's all
very clear in my little corner. I must admit that my understanding
significantly changed since. But my main point remains the same. I do not
have time to reply to all the related messages. So let me give it another
try to convey my point clearly: I don't see any reason to discuss library
interfaces and even more implementation without clearly stated problem
domain. How could you tell whether one interface/implementation is better
than another without understanding how it's planned to be used?
Now, based on library docs, we could try to give it some educated guess.
Unfortunately this lead me to decide that this library is not acceptable in
none of the potential problem domains.
Don't get me wrong. The library could be used by some users. But the same is
true for almost any one. But my criteria for library acceptance is really
simple: library should be usable for most users in problem domain. "Some"
users doesn't cut it.
So let's see.
Library to support program runtime parameters originated in different
>From my standpoint library is missing several crucial features to qualify in
a) No decent CLA parser
b) No conflict resolution.
If your parameter coming from different sources it's obvious that at
some point you need to decide which parameter to prevail: one from config
file or one from CLA.
c) No automated validations
Configuration even more then any other human input require strict
validation (more because it's frequently produced by third parties - not
library designers. That includes end-users, operation department remote
library user etc). We need some notion of "schema" support.
d) No automated processing/notification.
Many application prefer to build their runtime parameter support as
event driven system. No support for this is presented.
And these are just major deficiencies.
Library for permanent storage of application configuration that does not
have to be human editable .
My primary objection in this domain is that an alternative better solution
exist. I would use Serialization library and save/load directly C++ objects.
As for the "non human editable" clause,
IMO if you decide to present a way for the user to edit configuration
through application, no need to support also editing using some external
means. If you need some of the parameter to be externally editable (but not
from within application) - use separate storage for them.
Generic facility to manipulate hieratical data with permanent storage
My main objection in this domain is that author decided that his particular
data structure would be good enough for all usages. The word "particular" is
main offender here. I don't believe any "particular" data structure would
be good enough. Some novice users may use simple structure with class Leaf
and class Brunch. Some prefer generic tree one. Some need compile time
polymorphism only. Some could use runtime one. Some Would use boost::variant
IMO save/load side of the library like this would need to be made to work
with any data structure satisfying some concept. The same applies to access
methods (This is the reason why you need to switch to free function based
Facility to manipulate hieratical application configuration that have to be
human editable and application writable at the same time.
First of all I need to remark that this domain is kind of limited (and
internally conflicting IMO - I don't see why you need configuration editable
both ways). This option struggle from the same problem as option 3 -
hardcoded in-memory presentation. Also I believe that this domain also
require for loaders/savers to keep original formatting and/or comments. On
the other hand This library doesn't need CLA/registry support in this case.
While it's config files support should be more flexible.
Author need to decide which option match his understanding. But IMO library
in this current form isn't acceptable in any of them.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk