[Libxmlplusplus-general] Re: multi-node-types API changes



On Tue, 2002-12-17 at 22:25, Christophe de Vienne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Murray,
> 
> Having a quick look at what you commited, I have a few small remarks, beside 
> the fact that what you've done correspond almost exactly with what I was 
> thinking about (yeepee we do agree ;-)
> 
>  - The TextNode doesn't need all these constuctors since it has no name (well, 
> always the same),

Fixed in cvs already.

>  and no line number in libxml,

Go ahead and fix, though it seems like it should have a line number.

>  although we could 
> automaticaly give the parent line number to it.

>  - As I said a couple of week ago, I do agree with you on the problem caused 
> by the methods returning const references. So the name() method can become
> string name() const;

get_name(), as suggested, would be more normal. Let's do this
everywhere.

>  - Wouldn't a Clone() method simplify the Node(const Node * from) 
> implementation ?

Possibly. But do we really need these copy constructors anyway?

>  - don't you think we could get rid of the _initialised attribute ?
>  The only 
> case it is set to false is when the name of the node is empty. Is it really 
> necessary ? I have the feeling that not. If something wrong happens during a 
> node initialisation, then we throw an exception...

That sounds sensible.

> As far as the children API in the Node type, I guess that keeping it there 
> simplify it's use

I looked at the Xerces-C++ API. They don't seem to have any good reason
for it:
http://xml.apache.org/xerces-c/apiDocs/class_DOMNode.html#_details

I doubt it's part of the DOM spec (Does anyone have a URL)?

>  : there is not need to make any difference between all 
> types of node to go through a tree. A TextNode is a node with 0 children 
> after all.
> So let's keep it like this as you suggest.

Actually I'd prefer to change it because it obscures the API. But we can
do that later.

-- 
Murray Cumming
murray usa net
www.murrayc.com





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]