I think after getting a review on most of classes like NamespaceAttrNodeList,
we just need to do extend Gee.ArrayList<G> and port all code while dropping
GLib.List<G> API.

I think we don't gain any performance when using GLib.List vs. Gee.ArrayList at
specialized classes like NamespaceAttrNodeList, becouse at the end you copy all
data to internal variable, the same will be for Gee.ArrayList.

Porting to Gee.ArrayList requires lot of changes in other classes but will
decrease code on most classes and less Gee interfaces implementation.

Extending Gee.ArrayList will provides a Gee Container very easy with no effort.
Code for NamespaceAttrNodeList could be:

namespace GXml {

  public class NodeList : Gee.ArrayList { ... }

  internal class NamespaceAttrNodeList : NodeList {
        internal NamespaceAttrNodeList (BackedNode root, Document owner) {
            base (root);
            for (Xml.Ns *cur = root.node->ns_def; cur != null; cur = cur->next)
{
                this.add (new NamespaceAttr (cur, owner));
            }
        }
    }
}

Hi Daniel.

Last year the desire was to not depend on libgee in the API, so the public API wouldn't expose it, but we could use them internally.  People I consulted about it expressed 3 main concerns about having our API depend on it or using it for lists internally:

1. libgee's long term existence
* libgee is almost at a real 1.0 and it looks like it's sticking around, so maybe it would be OK to depend on it

2. its performance; GLib.List was used to keep internal structures lighter than libgee's collections at the expense of convenience in the case of GListNodeList, and ChildNodeList just references the linked lists from libxml2 to avoid a new list of references
* I'm not sure how real the performance (memory, speed) concern is, but someone (me?) needs to test with large XML documents for libxml2 vs. GXml-using-GList-and-libxml2-nodelists vs. GXml-using-Gee.List.  It would be great to just use existing list classes from gee, if the performance isn't actually worse. :) 

3. familiarity for existing developers with GLib.List over Gee (hence having a GList-like
* we're not actually using GLib (because we need additional features for the DOM API's requirements) so we're already forcing GList people to use a different API than they're used to, so it might as well be a Gee one; since we'd be extending it, anyway, we could add GList-like functions if in demand; so this is fine.

So, 1 and 3 are fine.  I'm fine gambling on libgee's existence (we can always change back to GList and libxml2's linked lists and still offer a Gee-like API if libgee dies).  However, 2 is important.  I will try to test it this weekend at the Boston Summit.

(class tree:

NodeList (interface)
  GListNodeList (based on GLib.List)
    TagNameNodeList
    AttrNodeList
    NamespaceAttrNodeList
  ChildNodeList (based on libxml2's linked lists)
    NodeChildNodeList:Xml.Node*
    AttrChildNodeList:Xml.Attr*
    EntityChildNodeList:Xml.Entity*)

(In reply to comment #2)
> Hi Daniel.
> 
> Last year the desire was to not depend on libgee in the API, so the public API
> wouldn't expose it, but we could use them internally.  People I consulted about
> it expressed 3 main concerns about having our API depend on it or using it for
> lists internally:
> 
> 1. libgee's long term existence
> * libgee is almost at a real 1.0 and it looks like it's sticking around, so
> maybe it would be OK to depend on it
> 

This is Ok for 0.8 I think.

> 2. its performance; GLib.List was used to keep internal structures lighter than
> libgee's collections at the expense of convenience in the case of
> GListNodeList, and ChildNodeList just references the linked lists from libxml2
> to avoid a new list of references
> * I'm not sure how real the performance (memory, speed) concern is, but someone
> (me?) needs to test with large XML documents for libxml2 vs.
> GXml-using-GList-and-libxml2-nodelists vs. GXml-using-Gee.List.  It would be
> great to just use existing list classes from gee, if the performance isn't
> actually worse. :) 
> 

That tests will be great, may be you want to change libxml2 container using GList, by using a hash table one, where key = node name and value is a Node. I think this will speed up access to XML documents, just remains reading high cost because first libxml2 parse work and then "copy" the structure to a Hash like Gee.HashMap<K,V>.

> 3. familiarity for existing developers with GLib.List over Gee (hence having a
> GList-like
> * we're not actually using GLib (because we need additional features for the
> DOM API's requirements) so we're already forcing GList people to use a
> different API than they're used to, so it might as well be a Gee one; since
> we'd be extending it, anyway, we could add GList-like functions if in demand;
> so this is fine.

At bug #685016, I've try to add a new class to Gee using a GList internal container, my idea was to expose the internal GList to allow anyone to use its API and avoid Gee, but found may redundant API and I have a question: Do we really need to use a GList or just port to Gee.ArrayList of Gee.HashMap?

I've stopped to continue fixing my implementation by asking what are the difference with both is just API or performance as you ask too.

> 
> So, 1 and 3 are fine.  I'm fine gambling on libgee's existence (we can always
> change back to GList and libxml2's linked lists and still offer a Gee-like API
> if libgee dies).  However, 2 is important.  I will try to test it this weekend
> at the Boston Summit.
> 

I don't know if we need to keep GList's API, witch is not Object Oriented. If Gee gives GXml new and powerful API useful for DOM then may be is time to forget GList. GXml is a new library with new API, not old C API from GLib and libxml2.

I've asked to Bug #685016, for performance measures if you're interested.

Have you considered to define Gee containers implementing its interfaces using libxml and then define new interfaces for GXml that will be implemented first by libxml and then with new re-implementation using just GObject and or Gee classes?

This will make GXml a set of interfaces to be implemented by:

a) First stage with libxml2

b) Second stage with pure GObject classes

Most of this interfaces could implement some Gee classes. For example a Node could implement Gee.List (and its dependencies) to access its childs using Gee's API, then add properties like node's tag (name) and its xml properties (declared as a list container too).

It's actually one of the intents to re-implement GXml with GObjects; wrapping libxml2 was chosen to minimise the amount of work to get a useful library up and running.  Given my inability to contribute much during the Fall/Winter academic semesters, I haven't gotten past using libxml2 yet. :) 

I like the idea of implementing Nodes as lists themselves, perhaps implementing Gee.List, but there's been strong opposition to relying on libgee in GXml, with some of the justification being uncertainty over whether it can be relied on in the future, and its current stability.  (Thanks for handling the Iterable/Traversable API changes; I wrote my own fixes while at the Boston Summit last year, but then never had enough time to properly test them ;_;).  Right now it's only really exposed in NodeList using Gee.Iterable, and that can be relatively easily removed if necessary.

I'll do a survey of opinions to see how people feel about depending heavily on libgee this summer, though.

(In reply to comment #5)
> with
> some of the justification being uncertainty over whether it can be relied on in
> the future, and its current stability. 

 The gee-0.8 API/ABI is suppose to be a long term and it should have not change (this include 0.10 and 0.12 which are/will be backward compatible).

Fixed on GXml 0.4