[ZOOM] Re: Ouch

Mike Taylor mike at tecc.co.uk
Thu Nov 1 15:30:58 CET 2001


> Date: Thu, 1 Nov 2001 12:55:25 +0100
> From: Adam Dickmeiss <adam at indexdata.dk>
> 
> > If so, then, your legitimate requirement would also be met by:
> > 
> > 	class connection {
> > 	 public:
> > 	   resultSet *search (query *q);
> > 	   resultSet searchStack (query *q);
> > 	};
> > 
> > (Not that I am necessarily claiming that this is a better way to
> > do it: just making sure I understand what the issues are.)
> 
> In principle that's OK, but is inelegant IMHO.

I agree.  But at least it's helped me (finally!) understand!

> That being said, I do understand why method search is
> there. Thinking: connections spawns a result set by doing a search
> (This is not a quote - it's just my thinking).

Yes.  This is the flavour of "where result sets come from", and it's
what the abstract API specifies.  However, I think it's OK for us to
make this clear in the C++ binding's _documentation_ (maybe also in
comments, but not necessarily) rather than enforcing it in the methods
themselves as I had originally envisioned.

> However, one could also say that a result sets is collection of
> records. And it's the result of "something", and one way or another
> record objects are fed into it. Records are sucked from the
> connection, so to speak!

I don't like this mental model so much.

> > BTW., and this sort of related, it may be that the search method
> > (or methods) (or the equivalent resultSet constructors) should
> > take a query (not a query*) as their argument.  Then you can say:
> > 
> > 	resultSet *s = c->search(prefixQuery("@attr exp1 1=1 targetinfo");
> > 
> > Instead of having to mess about like this:
> > 
> > 	prefixQuery q("@attr exp1 1=1 targetinfo");
> > 	resultSet *s = c->search(&q);
> 
> True. My immediate thought here is that (whatever creates a result
> set) should take a reference to a query. And, a refernce to a
> connection for that matter.

Well, I _suppose_ I agree.  But but but ...  But references _suck_!
(You can add about 30% of a ":-)" to that statement.)

What are the alternatives?

1. Plain connection/query.  I think that's fine, and it says exactly
	what's happening.  Only real downside is that it may be a tad
	inefficient if the objects are biggish, and need to be
	copied.  But we mustn't let such mundane concerns bother us:
	any tiny tiny overhead of copying (say) forty bytes at a time
	will be utterly dwarfed by network latency.

2. "Real" pointer to connection/query.  Doesn't allow the more concise
	programmeing style exemplified by
		resultSet *s = c->search(prefixQuery("@attr 1=1 foo"));
	which I think would be a real loss.

3. Reference.  It stinks, it stinks, it stinks ...  Bugger.  There's
	no real argument against it, is there?  :-)

Have I missed any?

> class smartSet : public resultSet {
> public:
>     smartSet(connection *c, query *q);
> };
> 
> smartSet::smartSet(connection *c, query *q) : resultSet(c, q)
> {
>     // stuff for my smartSet
> }
> 
> record *give_me_targetinfo3 (connection *c)
> {
>     prefixQuery q("@attr exp1 1=1 targetinfo");
>     smartSet (c, &q);                    // works
>     smartSet *s = new smartSet(c, &q);   // works too
>     smartSet *s1 = c->search(&q);        // works not
>     record *rec = s->getRecord(0);       // works (with smartSet)
>     // not deleting ... TODO
>     return rec;
> }

OK, I see what point you're making here.  Good point.

 _/|_	 _______________________________________________________________
/o ) \/  Mike Taylor   <mike at miketaylor.org.uk>   www.miketaylor.org.uk
)_v__/\  "By filing this bug report you have challenged the honor of my
	 family.  PREPARE TO DIE!" -- Klingon Programming Mantra




More information about the ZOOM mailing list