[ZOOM] ZOOM 1.0-g.hh OK (sas Re: zoom.hh)

Adam Dickmeiss adam at indexdata.dk
Wed Nov 28 22:48:53 CET 2001

On Wed, Nov 28, 2001 at 05:52:57PM +0000, Ashley Sanders wrote:
> Mike wrote:
> > So I do think we're going to be using references in a lot of places,
> > despite my loathing of them.  ("foo&" indeed!  Pah!)
> > [snip]
> > 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.
> If getRecord() is returning a reference to a record, then to get
> your own copy of that record, something like the following is needed.
>   try
>     {
>       SUTRSRecord sMyOwnCopy =
>          dynamic_cast<const SUTRSRecord &>(sResultSet.getRecord (0));
>       cout << sMyOwnCopy.render () << endl;
>     }
>   catch (bad_cast)
>     {
>       cerr << "oops, wasn't a SUTRS record" << endl;
>     }
> Which I think isn't too cumbersome to write. I think that even if
> we were using pointers, you'd still need the dynamic_cast.  With
> pointers you have to check for a null pointer returned from the
> dynamic_cast. With references you have to catch an exception. If
> you check the syntax of the record first (with the recsyn()
> function) then you should be able to guarantee that you'd never
> have to catch a bad_cast exception or look for a null pointer.

Your example made me realise that if we're returning records
owned by a result sets, then I'd vote for the pointer version,
rather than the reference version. In the pointer version the
NULL pointer, elegantly, indicates "non-present", whereas in the
references version it causes trouble. Using pointers is closer
to the C binding (not that it's essential).

> But really, I can't see a reason why you would want your own
> copy of a record. The resultSet object is already a handy
> container for keeping them in.

Certainly I can see a use for a autonomous record object. What
happens if you need to search twice on a target that doesn't
support named result sets? Well, maybe the client is smart enough
to keep the records in caches, maybe not. That the C++ users'
view. Now, consider what happen if you attempt to build a Perl
(or similar) wrapper on top of the C++ binding. That implementation
will have trouble exposing the record(s) as objects unless
the implementation makes sure that no result sets are destroyed
(and introduce dangling references). OK, one might be clever
and do reference counting, etc.. But that's too much suffering,
IMHO. Instead one would completely hide the record objects and
offer operations (render, etc) on result sets that returns what
you want.

If we stick to pointers and clone, I think we're OK. So what I'm saying
is that I'm happy with zoom-1.0g.hh as it is.

-- Adam

> Ashley.
> -- 
> Ashley Sanders                                a.sanders at mcc.ac.uk
> COPAC: A public bibliographic database from MIMAS, funded by JISC
>              http://copac.ac.uk/ - copac at mimas.ac.uk
> _______________________________________________
> ZOOM mailing list
> ZOOM at indexdata.dk
> http://www.indexdata.dk/mailman/listinfo/zoom

Adam Dickmeiss  mailto:adam at indexdata.dk  http://www.indexdata.dk
Index Data      T: +45 33410100           Mob.: 212 212 66

More information about the ZOOM mailing list