[ZOOM] Re: Ouch

Adam Dickmeiss adam at indexdata.dk
Thu Nov 1 12:55:25 CET 2001


On Thu, Nov 01, 2001 at 10:59:53AM +0000, Mike Taylor wrote:
> Adam (and others),
> 
> Now that we have the ZOOM list, could we please make an effort to
> remember that replies need go _only_ to the list, not also to the
> originator.  Otherwise, the originator gets two copies.  Not the end
> of the world, but worth avoiding if/when you remember.

So true.
 
> > Date: Thu, 1 Nov 2001 11:38:53 +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. 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). 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!

> 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.

> The more I look at this interface, the more I think that I was overly
> seduced by the C mindset in putting together the initial version (and
> to be fair to myself, I do admit that in the introductory prose!) with
> the result that pointers predominate in a way that is not idiomatic
> C++.

I really do understand the ideas you had here. Connections spawns
result sets when you search, basically.

> Thanks for battling on until you finally managed to get me to see
> this.  You've been very gracious about it :-)
> 
> > Furthermore when resultSets create resultSets you have a way to use
> > a different (your own) new operator. That doesn't work when
> > connections create result sets.
> 
> Once again, I'm afraid I don't understand what point you're making.
> Is it a duplicate of the above?  If not, you'll have to explain it.

I thought this was not such a big issue, but it's essential. The search
method in its current form doesn't allow that you specialize your
resultSet (inherit from it). Let me show some code. I hope it
speaks for itself.

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;
}

// Lunch time. Some stuff unanswered.

// Adam



More information about the ZOOM mailing list