Re: [Libxmlplusplus-general] resume of one day's work

On Tue, 2003-02-04 at 08:21, Stefan Seefeld wrote:
> hi there,
> I'v just checked in the latest bits and pieces of today's round
> of enhancements. Here is a list:

I haven't looked at this yet, but didn't I say that you shouldn't take
cvs access as permission to just check in whatever you like? The need to
revise your patch 6 times should have shown you that you probably need
to go a bit slower. Your arrogance is beginning to astound me.

> * create a 'Document' type
> * make 'Attribute' a subclass of 'Node'
> * enhance the tree manipulation API, adding a Node::child_iterator
>    type, as well as new 'insert_child', and 'append_child' methods
>    (in accordance with the usual STL nomenclature)
> * remove more memory leaks (SaxParser now has its own 'AttributeMap',
>    independent from Node types
> * new 'Node::find' and 'Node::get_path' methods for use with xpath lookup

Who gave you permission to make these major API changes? As far as I
know we have not branched yet. Now we will have to do a lot of work to
branch and revert these changes in the 1.0 branch.

> All this is illustrated in a new example in examples/dom/. The example takes
> an existing docbook 'article' and modifies it, and does a simple (xpath
> based) validation test.
> Here are some further enhancements I'd like to work on:
> * add a 'Visitor' class to get rid of all the dynamic_casts in the existing
>    examples

Let's patches for all the other stuff please, and let's apply them until
we've branched.

> * clean up the tree access/modification API. In particular:
>    - get rid of all methods involving NodeLists. Use iterators instead.
>    - get rid of [add,get] *_content (iterators, again...)
>    - define what 'get_content' should do if this isn't a text (etc.) node.
> * decide who can create Nodes, who owns them if they are taken out of a document,
>    etc. May be a 'Store' object may help...
> What is the reason for the libxml++ code to be split over a set of subdirs ?
> Is that really necessary ?

Yes. It's organisation.

>  Now that 'Attribute' is a node, it is also inconsistent.
> I would suggest to put all libxml++/nodes/ source files into a single place with the
> rest.
> Oh, and can we take out the call to './configure' from the script ?

No, I'd rather that we didn't.

> I'd like to be able to configure (and build) in a separate build tree, which
> currently isn't possible.

Feel free to make your own locally.

> Any comments concerning the new code (please look into the examples/dom/ demo !)
> are highly appreciated...
> Regards,
> 		Stefan
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> _______________________________________________
> Libxmlplusplus-general mailing list
> Libxmlplusplus-general lists sourceforge net
Murray Cumming
murray usa net

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