From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-11-04 09:59:55
>Janusz Piwowarski wrote:
> > Stefan Seefeld wrote:
> >>Now I hope that someone will actually start to send comments about the
> >>actual API / code I propose. ;-)
> > I not sure why you do not use of overloaded append and insert members.
>Assuming you are talking about the element class and its methods to add
>various child node types, I don't quite see how I could overload the
>name 'append' and 'insert', as most versions have the same signature.
>E.g. 'insert_element("foo")' will add (and return) the element
node.insert( element( "foo" ));
>while 'insert_comment("foo")' will add (and return) the comment
node.insert( comment( "foo" ));
> > I'd like to change begin_children and end_children to
> > std::pair<children_iterator, children_iterator> children (the same with
> > attributes).
>...or add a container proxy so one would write element->children().begin()
>instead of element->begin_children(). I'm not sure there is any gain. It
>seems to be a purely esthetical issue.
I prefer the container proxy as it is more familiar to STL users - (
children.first, children.second ) is harder to understand what is meant by
first and second.
I would like to see STL techniques (like the children and attributes types
being Container-like types), that would allow the leverage of existing STL
and boost code.
Since an XML document is a tree structure, it might be useful to have a
generic tree library first (using STL principles) so you could do something
typedef nary_tree< xml::node > document_fragment;
or even leverage the Boost.Graph library.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk