From: Jose (jmalv04_at_[hidden])
Date: 2006-04-28 11:03:10
On 4/28/06, Marcin Kalicinski <kalita_at_[hidden]> wrote:
>
> Hi Jose,
> The scope of the library is beyond program configuration. It can also be
> used to manipulate DOM-like structures (which are trees), pass data inside
> program etc. ProgramConfiguration would be misleading, it would suggest
> the
> library is a superset of Program Options, which it isn't.
For that wider scope I think the library is completely unappropiate
because:
1) It doesn't use a generic container, which limits its use to very simple
DOM structures
2) It doesn't follow any of the standards: W3 DOM and XPath
3) It devalues what is currently expected from Boost libraries
Also, the simplicity argument is not good for DOM-like structures b/c it's a
broad
problem domain. I truly believe the PT fits the category of "Utilities" more
than
a Boost library. My vote then was meant to be a strong NO.
> tree.hh is GNU GPL licensed. Cannot use it in boost. Also, because it is a
> generic tree container, its interfaces are inevitably generic as well. It
> has very different strucuture from ptree, for example it does not have
> keys,
> so you cannot use paths. It does not provide any type-conversion
> mechanisms.
> It would require a large facade to be used in a role of property tree.
I mentioned tree.hh as an example of what should be provided but a better
example is
the Tree Container Library ,
http://www.codeproject.com/library/tree_container.asp
The author plans to submit it to boost, so maybe we should wait for that
I believe Boost has to aim for state-of-the-art libraries not utilities.
1) There is nothing bad about generic interfaces. They allow you to handle a
wider
set of DOM structures.
2) The argument it doesn't have keys is wrong, because you have a node
object
(and you can have a key). And the way PT handles paths is bad (at least for
my requirements and as pointed out in a separate thread)
Sorry to be so negative about the proposed library. I am not a Boost expert
but I have
used tree.hh and other libraries in this problem domain. I liked your
simplicity
argument for the program configuration domain but trying to broaden the
scope
as a library for DOM-like structures cleary makes the library inappropiate
as pointed out
in the arguments above
Regards