[ZOOM] Re: Ouch

Mike Taylor mike at tecc.co.uk
Thu Nov 1 11:02:08 CET 2001


> Date: Wed, 31 Oct 2001 22:21:42 +0100
> From: Adam Dickmeiss <adam at indexdata.dk>
> 
> NOTE NOTE. Probably first email on mailing list. 
> ZOOM SPAM coming through!

Excellent!  I've removed the other recipients (a.sanders at mcc.ac.uk,
quinn at indexdata.dk, adam at indexdata.dk) from the distribution list of
this message, since the list now seems to be up and running.

> > Why is this more sensible?  Because you avoid calling copy
> > constructors when you put them in an array?
> 
> First, I still don't wee why we're forced to use pointers for
> results sets (C++ mostly).

Well, that's exactly what I was asking!

> Second, I don't understand why "parent" objects create childs (both
> C and C++, really). What if we had a public constructor:
> 
> for the resultSet
> class resultSet {
>   public:
>     resultSet(connection *c, query *q);
>   ...
> };

What's the point?  If we added this, wouldn't the following two lines
be _exactly_ equivalent?

	resultSet rs = c->search(q);
	resultSet rs = new resultSet(c, q);

Then why provide two ways to say one thing?  That's just potential for
confusion.  Perl motto to the contrary notwithstanding (TMTOWTDI), we
should provide One Way.  And the former, IMHO, is a much clearer
expostition of what's going on.

> That would allow us to make two versions of my Explain example
> depending on the needs. This is very BASIC I realize - I just
> need to know why we didn't go for it. Tell me I'm missing something!!
> 
> record *give_me_targetinfo (connection *c)
> {
>     prefixQuery q("@attr exp1 1=1 targetinfo");
>     resultSet s(c, &q);
***or  resultSet s = c->search(q);
>     return s.getRecord(0);
> }
>
> record *give_me_targetinfo2 (connection *c)
> {
>     prefixQuery q("@attr exp1 1=1 targetinfo");
>     resultSet *s = new resultSet(c, &q);
>     record *rec = s->getRecord(0);
>     delete s;
>     return rec;
> }

I think we're confusing two issues here: one is the issue of whether
the C++ binding should be passing actual objects rather than pointers,
and the other is whether we want an explicit resultSet constructor.

> This thing compiles. I had to add 
>  record *getRecord (size_t i) const;
> for class resultSet.

Because you were using 1.0e, right?  It's in 1.0f.

> > There are _some_ issues with copying as the state of an object can
> > change -- especially result sets.  Consider the following code
> > (WARNING: not tested, sketch only) as it would be if we returned
> > actual result sets from ZOOM::connection::search() instead of result
> > set pointers:
> > 
> > 	resultSet rs = c->search(prefixQuery("@attr util 1=4 99"));
> > 	resultSet rsCopy = rs;
> > 	record *rec1 = rs->getRecord(1);
> > 	record *rec2 = rsCopy->getRecord(1);
> 
> I don't think we should define things like "copying" resultSets
> at this point (no copy constructor).

I agree (as does Ashley).  We should flatly prohibit this stupid
behaviour.

 _/|_	 _______________________________________________________________
/o ) \/  Mike Taylor   <mike at miketaylor.org.uk>   www.miketaylor.org.uk
)_v__/\  "A player who is not conducting himself as a professional is a
	 cheat who betrays his fans" -- Gerard Houllier.




More information about the ZOOM mailing list