[ZOOM] Option Handling (Was: Value Returned from Set Option (Was: Catching up))

Mike Taylor mike at tecc.co.uk
Fri Nov 16 11:50:53 CET 2001


> Date: Thu, 15 Nov 2001 12:52:59 +0100
> From: Adam Dickmeiss <adam at indexdata.dk>
> 
> > OK, by inspection, Adam's C binding has:
> > 
> > 	Z3950_options_set() stores a _copy_ of the option value passed
> > 	in, and returns nothing -- which I think is the solution we're
> > 	converging on for the C++ binding too?
> > 
> > 	const char *Z3950_options_get() returns a reference to the
> > 	option-clump's own copy of the value -- which is therefore
> > 	valid until the option-clump is deleted.  Again, I think this
> > 	is what we're converging on for C++.
> 
> That's how I did it for the underlying Options layer which is
> somewhat outside the scope of ZOOM.

Ah yes, I see.  Although this may not remain outside the scope of ZOOM
if, as several people seem to want, we add the ability to pass option
clumps into many of the methods -- e.g. connection::search(),
resultSet::record().

e.g.

	namespace ZOOM {
	    // ...
	    class option { // singular
	      public:
		option(const char *key, const char *value);
		friend class options; // so it can get the key/value out
		// no other public interface at all
	    }

	    class options { // plural
	      public:
		options();
		options& add(option& o);
	    }
	    // ...
	}

Then you could go:

	options o;
	o.add(option("foo", "val1")).add(option("foo", "val"));

(An alternative that I prefer to ignore is options::operator<< as a
synonym for the add() method so you can say:

	o << option("foo", "val1") << option("foo", "val");

which I admit is cute, but cute is not the same thing as good!)

Actually, on mature reflection, the better alternative might be to
junk the option (singular) class completely, and just make the
options::add() method take two "const char*" parameters -- key and
value.  So:

	o.add("foo", "val1").add("foo", "val");

Yeah, that's much better, isn't it?

> For the connections and result-sets I used the form as of the
> abstract API. And that is both wrong in my implementation [...]

Ah yes, the returning-a-handle-on-stale memory joke.  Gotcha.

> and we don't seem to want it (return previous value that is).

Indeed.

> C doesn't do overloading so making functions set/get for
> options makes sense. If I don't hear anybody shout that's
> what I'll do, before next YAZ release.

Absolutely, no question that this naming dichotomy is right for the C
binding.  The question is whether the C++ binding should follow it in
using different names for the Get Option and Set Option methods.  And
my feeling is, probably, yes.

 _/|_	 _______________________________________________________________
/o ) \/  Mike Taylor   <mike at miketaylor.org.uk>   www.miketaylor.org.uk
)_v__/\  "Looks like it's time to over-technicalize this previously
	 tame post" -- Mickey Mortimer on the dinosaur mailing list




More information about the ZOOM mailing list