[redland-dev] class members.

[Dave Beckett]

On Sat, 27 Mar 2004 22:25:02 -0600
César López Natarén <cesar at ciencias.unam.mx> wrote:

> Hello.
> 
> I'd like to know if there's a place where I can see which are the
> public members of Redland's classes (without seeing the code ;-)) and
> inheritance hierarchy.

That's tricky to answer since Redland's API isn't quite defined in those
terms.  In order to get a cross-language OO API, there is a rather flat
looking set of functions available.  How I use Objects in C is described
in http://www.redland.opensource.ac.uk/docs/api/objects.html

Parts of the Redland API isn't so useful for user level code, rather
than for implementing new redland storage implementations, so the API
that's exposed to the higher level languages is a useful subset, and
this is defined in one file that you can look at - Redland.i in
the source tree.  From CVS:

  http://cvs.ilrt.org/cvsweb/*checkout*/redland/librdf/Redland.i?rev=HEAD&content-type=text/plain

So, if you read that file, you can get the exposed classes and the
(useful) public member functions.

As to the hierarchy; flat.  When you want a particular implementation of
an interface, say, a type of storage, you ask the librdf_new_storage
constructor to make one and return it for you.  This hides the issues of
inheritance for languages that don't understand it.

However, in ones that do understand it, it makes sense to create
helper classes that subclass things like Storage.  You can see this in
the python API documentation (even if you don't understand python):

  http://www.redland.opensource.ac.uk/docs/pydoc/RDF.html

There are only a few places it would make sense to create a hierarchy -
where there are multiple implementations of things such as Storage,
Parser, Model.  And maybe you could make subclasses of Node to allow
URINode, LiteralNode, BlankNode to exist on their own.

Hope that helps

Dave