Re: [gdome]A(bstract) DOM

[Tobias Peters <t-peters gmx de>]

On Wed, 14 Nov 2001, Luca Padovani wrote:
> Dear Gdome2 users,
> (and Tobias in particular)
>
> I've been studying at a C++ wrapper for Gdome2 for a few days, looking
> also at Tobias' work. The library I'd really like to use is something
> with the following characteristics:
>
> 1) it should provide a set of abstract DOM classes, basically a
>    mere C++ hierarchy of interfaces (= classes with pure virtual
>    methods only) following DOM IDLs
>
> 1bis) such abstract classes should be carefully designed so that
>    the user is "forced" to use them the right way. For
>    example, I'd like to have all classes except DOMImplementation
>    to have protected constructors, so that an object of that class
>    can be only constructed via the DOM interface, and not by accident
>    with the new operator.

You cannot instantiate abstract classes. No accident possible here.

>    Similarly, having a protected destructor prevents users to invoke
>    delete on classes, thus enforcing the use of ref/unref mechanism
>    (but see point 4))

see reply to 3)

> 2) it should provide a DOM compliant class for string management
>    (that is, where strings are really encoded in UTF16)
>

Just for being DOM compliant, or do you actually see any use in it? I
thought of this, too, but I don't believe anyone would use the UTF16
interface.

> 3) it should be possible to "instantiate" the abstract library to
>    a variety of different implementation. For example, we should be
>    able to instantiate abstract classes at point 1) with suitable
>    implementations relying on the Gdome2 engine. But it should be
>    also possible to do the same with a different DOM implementation,
>    eventually something which is completely native C++ and just
>    relies on some SAX2 implementation (which libxml2/3 will
>    hopefully support one day). The final applications should know
>    very little (or nothing) about what's behind this DOM.
>

So you want generic C++ language bindings for the DOM, similar to the Java
and ECMAScript language bindings by the W3C DOM WG. Tricky. You would have
to decide for how memory is managed in an abstract API. You wrote that you
want ref/unref methods for that.

Users of a C++ API should IMHO either not bother with memory management at
all ( -> smart pointers ), or have total control over the objects they
create ( -> may delete them ).  The first two releases of libgdome-cpp did
it the second way. You can still download libgdome-cpp-0.0.2 from
http://download.berlios.de/libgdome-cpp/libgdome-cpp-0.0.2.tar.bz2
to see how this was done.

With gdome2 in particular, you would introduce a reference counted C++
layer around a reference counted C layer around libxml.

You can still introduce reference counting on top of objects that are
designed to be deleted directly by creating a new class that inherits from
this and a "Refcounted" class.

> 4) provide a layer of smart pointers which is separate from the
>    hierarchy at point 1) (much like xerces). This gives the user
>    the freedom to choose at which level he/she wants to access
>    the library (it is well known that smart pointers often introduce
>    overhead). Furthermore, smart pointer classes can
>    be created regardless the actual implementation at point 3).

Of course, they introduce overhead. The ammount of overhead depends on how
the application uses the smart pointers: Instead of

if (el.hasChildNodes()
    && el.firstChild().nodeType() == ELEMENT_NODE
    && el.firstChild().nodeName() == "ex"
    && Element(el.firstChild()).hasAttribute("att"))
  return Element(el.firstChild()).getAttribute("att");

a programmer should write

Element child = el.firstChild();
if (child.null() == false
    && child.tagName == "ex") {
  DOMString att = child.getAttribute("att");
  if (att.null() == false)
    return att;
}

There are certainly times when this is not enough performance. But at the
moment, I don't want to bother with it.

> 5) the possibility to instantiate the library at runtime. I mean,
>    I want to be able to decide at runtime what underlying implementation
>    I want to use. Here is Gdome2, there is something else. This
>    reduces the dependencies of the binary distribution package, provided
>    that it's split into several different libraries, one for each
>    possible implementation. It's also a way for the library to adapt
>    more flexibly to the characteristics of the system.

I think the necessary methods for this will be part of DOM Level 3.

> I believe Tobias' code can be very helpful for this, and even though
> I know nothing about Ruby I'm pretty sure it can be adapted so to
> achieve most of the points above (also, I'd like to have one .hh file
> for each class, not a huge .hh file with everything, same for the
> implementations).

No need to do this in Ruby. Just take the generated C++ code and modify
it. I suppose you would want to start with the code in libgdome-cpp-0.0.2,
since it's the last release that uses native pointers instead of "smart"
pointers.

> As usual, further discussions, comments, suggestions are more than
> welcome. I can provide (for free) code, time (limited) and enthusiasm.
> I'd really like to make this C++ library comfortable, so that
> more and more users will be using it (aren't you tired of C? ;-) )

Indeed. But then C++ is only one small step in the right direction.
Sometimes you can't go further because of performance. But if you want to
use a really beautiful language, you have to make two steps and switch to
Ruby :-).

BTW, have you tried to work on an Ocaml wrapper?

Bye, Tobias