[ZOOM] hello and first impressions of the C++ bindings

Mike Taylor mike at tecc.co.uk
Fri Nov 9 12:38:37 CET 2001

> Date: Fri, 9 Nov 2001 00:15:00 +0100
> From: ja7 at dbc.dk
> > In case anyone didn't "get" that, the message is that I am
> > starting to think that the rawdata objects are an extra layer of
> > added complexity for no or marginal gain.
> This a sutestion for what ?

At the moment, if you want to get the chunk of bytes from a USMARC
record, you fetch record, then its corresponding rawdata object,
then get the bytes from that:

	record *r = rs->record(1);	// it's a ZOOM::USMARCRecord
	data *d = r->rawdata();		// it's a ZOOM::USMARCData
	size_t nbytes;
	const char *bytes = d->bytes(&nbytes);

I am suggesting that we junk the "data" class (and its subclasses such
as USMARCData), and just make bytes() a method on the USMARCRecord
class directly.  It'll similarly be defined on SUTRSRecord and others,
but _not_ on GRS1Record which will have some other, more appropriate,
method or methods to get hold of the "raw" data

(I put the word "raw" in quotes there because it won't be fully raw
like the MARC data, but munged into some sort of tree structure -- as
it is in the Perl implementation: see
for one way of representing it.)

> I can't figure out where the rawdata object i a layer.  to me it
> eams to be on top of the record class??

Sort of on top, sort of parallel.

Once again (I think for the third time), I call upon anyone who
remembers why we introduced the rawdata objects to remind the rest of
us what the thinking was.

> Personly i thing all record's shut be returned as a raw data, and a
> easy way for the user to decode it with libs for handling different
> encodings.

I think we agree, then -- if I understand you correctly.

> If zoom defines a auxillary lib for handling GRS-1, alle that is
> needed from the core zoom records is the bytes that is quiqly parsed
> on to a lib returning som nice classes.

I am intrigued by Adam's suggestion that we should consider handling
_all_ tree-structured records simply by translating them into XML, and
leaving all the work of grokking them to other, existing software.
Does anyone else have thoughts on that?

> > The next version should specify how this option's value can
> > specify a list rather than a single database name.  In the
> > interests of simplicity (and since we're all char*y), I suggest a
> > comma-separated list.
> The c++ has many nice ways of handling lists and why allow for the
> use of language native list handling isted of encoding stuff in
> char*.

It's hard to define the option() methods to allow arbitrary-typed
value arguments, and even harder to allow them to return
arbitrary-typed values.  We've using char* everywhere simply for the
same of uniformity.

> The perl language binding shut allow for using perl lists.

It does -- because Perl is loosely typed, that's not a problem.

> > It would gain us nothing.  (We ought to have a FAQ about this!)
> > The char*s are opaque tokens and are never manipulated, so we
> > don't need any of the functionality that std::string would offer.
> Jep make it easy for implementing memory handling, eg.  if the
> libary is not "strduping" the val argument this valid c++ code wil
> fail
>     void readAndSetDatabase(connection& c) {
>         string newBase;
> 	cin >> newBase;
> 	c->option("databaseName",newBase.c_str());
>     }; // at this point the mem given to the option command is freed :) 

Well, you're right that if the option() method's implementation is
broken then this code will break.  I suggest, then, that we write
non-broken versions of the option() method.

> > OK, does the existence of a private constructor actually change the
> > public interface of a C++ class?  What a stupid world!  So our
> > public, abstract version of the binding's header-file needs to include
> > private methods, so that their existence can imply the absence of the
> > ability to copy connections?  Arrrgh!
> Don't Arrrgh when the compiler is able to help you. the Current 
> version of the C++ bindings jyst have a implicit defined copy 
> copy constructor with type connection(const connection&) and 
> if you don't want it to be public move it to private. 
> The Problem is that people tend to forget stuf that is implicty
> defined. I forget the precise roules on a regular basis. 

Indeed.  Suggesting that the rules are too complex, confusing and
contradictory.  The fact of the matter seems to be that a class's
_public_ interface -- that is, the set of operations that pure client
code can invoke -- is affected by what's in that class's _private_
section.  That _has_ to be a mistake in the C++ definition.

> > This is an excellent point - we don't want to preclude the use of
> > non-standard record syntaxes.  Anyone want to propose a good way
> > to handle this?
> in the c++ binding why not just. 
> typedef std::string oid;
> And the a lost of const oid for the ones we know. 
> const oid OID_DANMARC("1.2.840.10003.5.14");

Well, string representation doesn't seem far wrong: though in
accordance with the way we're doing all this stuff, we'll do it with
Boring Old Char Star rather than these dangerously sexy new types.
(Automatic string -> char* conversion should mean that you can do all
the things you want to do anyway, right?)

So Ashley, how about:

	class record {
	    // no definition of enum recordSyntax
	    virtual const char *recsyn () = 0;
	    static const char GRS1[] = "1.2.840.10003.5.105";
	    static const char DANMARC[] = "1.2.840.10003.5.14";
	    // etc.

> > See the discussion archive at http://www.indexdata.dk/pipermail/zoom/
> > for some insight into this.  You're right, the diagnostic interface
> > remains muddy -- perhaps because the abstract API allows too much
> > leeway.  Who will propose a GUT to fix this?
> What is a GUT? 

As Rob says, a Grand Unified Theory.  Sorry, should have spelled it

 _/|_	 _______________________________________________________________
/o ) \/  Mike Taylor   <mike at miketaylor.org.uk>   www.miketaylor.org.uk
)_v__/\  "Baroque music is like an Agatha Christie novel: you always
	 sort of know what's going to happen" -- Sarah Bickers.

More information about the ZOOM mailing list