Re: [Libxmlplusplus-general] Adding STL-container-like methods to Node instead of returning a container instance

[Stefan Seefeld <seefeld sympatico ca>]

Murray Cumming wrote:

> Why is this necessary/desirable? I'm concerned that, if we decide to
> make xmlpp::Node look like std::list or std::vector, we should add _all_
> of the common STL-container methods.

yes, this worry seems reasonable. However, there are a number of 
containers in STL, not all are as rich as std::vector.

I just think it is intuitive to use iterators to walk over child nodes
(or attributes). In particular, instead of doubling the semantics of
libxml2 (which uses doubly linked lists to hold child nodes), we could
access that container directly instead of using our own ('NodeList').

Of course, if the container itself is temporary, such as in case of
the 'NodeSet' (a name defined in the XML spec) which is returned by
an xpath 'find' operation, there is no way around.

> For instance, we should add a
> reverse iterator, and the front() and back() methods. Then lots of
> STL-container-like methods will be mixed up with the Node-specific
> methods and it won't be clear what is meant to be used for what
> functionality. And we might have made the API bigger and less clear
> without adding functionality.

agreed. The API should not add methods that are strictly convenience
tools.

> I see that you have tried to avoid this by using method names such as
> children_begin() instead of begin() but then I think it's less
> STL-container-like.

well, it's enough to be used as an STL container:

template <typename iterator>
void my_function(iterator begin, iterator end)
{
  // do something with the content here...
}

Element *element = ...;
my_function(element->children_begin(), element->children_end());

which is rather elegant and intuitive (and consistent with STL),
don't you think ?

> If it's absolutely necessary then maybe we could consider an auxillary
> object, just to separate that part of the API.
>
> For instance,
>
> NodeChildren& nodeChildren = node.children();
> for(NodeChildren::iterator iter = nodeChildren.begin(), iter !=
> nodeChildren.end(); ++iter)
> {
>    ...
> }

Well, it's this temporary object creation which I tried to avoid.

Stefan