[ZOOM] Re: zoom.hh

Mike Taylor mike at tecc.co.uk
Wed Nov 28 18:10:14 CET 2001

> Date: Mon, 26 Nov 2001 10:35:15 +0100
> From: Adam Dickmeiss <adam at indexdata.dk>
> > > Re: why did we change how resultSets are created.
> The foo and foo * AND the ability to derive from it.

Ah yes, deriving!  That was it, thanks.  I've updated the web page

> The automatic construction is "usual" C++ style that saves
> programmers from bothering when destruction takes places, makes the
> program more readable and causes less programming errors (leaks that
> is).

Yup, I already wrote up that reason.  See
section "Searching now done with resultSet constructor".

> If we go the pointer-always route then the description of the API
> might be simpler as I've written in a previous email, i.e. the
> connection is a "result set factory", etc.

Hmm.  I think we'd all agree that the simplicity of API description,
while desirable, is less important than convenience of use, where
there's a conflict between the two.  In any case, we hope most people
will first read the Abstract API, which will give them the nice,
simple, high-level overview that they'll need before leaping into the
nitty-gritty details of how that's presented in C++.

So I do think we're going to be using references in a lot of places,
despite my loathing of them.  ("foo&" indeed!  Pah!)

> > I'm addressing the (I think) more fundamental problem of whether a
> > record returned from getRecord() "belongs" to the result set or to the
> > application (or to someone else entirely.)
> > 
> > [excellent summary snipped]
> >
> > Just want to be sure I'm not missing anything.
> I don't think you have.

OK, thanks.

> But observe that you could make the API more "clean" by saying that
> instead of temporary pointers/referenes you are in fact returning an
> INTERFACE for dealing with records (buzzwords are wonderful:).

Well, again that's the job of the Abstract API.  The C++ binding
unfortunately has to go beyond that into the messy details of how we
represent things, which includes owenership/autonomy of the various
kinds of objects.

So we seem to be agreed that in some circumstances, we want records to
be "owned" by their result sets, so that we don't have to bother
explicitly freeing them; and in others, we want the records to be
fully autonomous, so that we can return them from scopes in which they
are obtained from transient result sets.

I can think of three, maybe four ways of expressing that choice in the
interface.  I'll tell you what they are tomorrow, and then we can
choose which is least offensive.

> As for exceptions I don't have a problem. Never used them, really.
> The C binding will not have them, so the C binding will use
> something different.

Indeed.  Which is a mild argument for not using them in the C++
binding, but shouldn't stop us if it's plainly The Right Thing.

 _/|_	 _______________________________________________________________
/o ) \/  Mike Taylor   <mike at miketaylor.org.uk>   www.miketaylor.org.uk
)_v__/\  "If are a fascinating writer, then you follow a deeper set
	 of rules which make the normal ones irrelevant.  If not,
	 then you need to follow the normal rules until you get
	 fascinating" -- Greg Gunther.

More information about the ZOOM mailing list