Re: [libxml++] Adding STL-container-like methods to Node instead of returning container instance (xmlwrapp)

[Jonathan Wakely <cow compsoc man ac uk>]

On Fri, Feb 07, 2003 at 04:20:50PM -0500, Stefan Seefeld wrote:

> it seems we are converging towards the following:
> 
> class Node
> {
> public:
>   NodeList get_children();
>   NodeList get_attributes();
>   //...the rest
> };
> 
> class NodeList
> {
> public:
>   class iterator;
>   class const_iterator;
>   iterator begin();
>   //...and the rest
> };
[snip]
> With my proposed NodeList class (which will comply to STL API), only
> a single xmlNode pointer needs to be copied, as the 'iterator' now
> can be implemented in terms of libxml2's internal linked list structure,
> not as an iterator over a std::list. That's the main benefit.

Nice.

> There is one remaining issue: we'd need a 'ConstNodeList' type that
> provides read-only access to the children. If you hold a const
> node reference, you shouldn't access child nodes in r/w mode, i.e
> the corresponding 'get_children() const;' method shouldn't return
> a NodeList, as you get r/w access with that.
> (The issue exists since we don't return a reference to an internal
> container, but a new one, so we can't restrict access).

What if a NodeList cannot be constructed from a const NodeList ?
e.g. its copy ctor takes a non-const reference like auto_ptr, or it has
private copy ctor to make it non-copyable.

That would allow a const Node to return a const NodeList, which can't be
turned into a non-const NodeList, and so will only yield read-only
const_iterators. This gives the desired effect of not being able to
modify the children of a const Node.

It might still be necessary to have a separate ConstNodeList class, but
IMHO it would be better if "deep-constness" can be done correctly with a
single NodeList class.

jon

-- 
"The tools we use have a profound (and devious!) influence on our
 thinking habits, and, therefore, on our thinking abilities."
	- Edsger Dijkstra