Kay Röpke wrote:
Hi!
On Aug 31, 2009, at 10:36 PM, Eric Day wrote:
libdrizzle will optionally allocate memory for your objects if you
do not. For example, you can do:
/* User allocated. */
drizzle_st drizzle;
drizzle_create(&drizzle);
or:
/* libdrizzle allocated */
drizzle_st *drizzle;
drizzle= drizzle_create(NULL)
What do folks think about this interface? Would having two functions
be preferable to just one? For example:
drizzle_st drizzle;
drizzle_init(&drizzle)?
and:
drizzle_st *drizzle;
drizzle= drizzle_new(void); /* Calls malloc() and drizzle_init() */
My preference is to have two functions, where drizzle_new could be
regarded API sugar (since it's a thin wrapper around init).
Also, having one function do both is slightly awkward from a function
prototype perspective: In the user-allocated case you would be
discarding the
return value, which I get uncomfortable about when reading code. Also
there would be two paths of passing out a return value, which isn't so
clean either.
++ I support the new and init separate functions.
Next, should the default behavior of drizzle_query be to wait for
the result header or return immediately and require another function
to read the result header? This is currently a behavior flag so you
choose either one, but we still need a default behavior. For example:
drizzle_query("SELECT ...", result);
/* Start using result. */
or:
drizzle_query("SELECT ...", result);
/* Do something else here since we didn't block on the result read(). */
drizzle_result_read(result);
/* Start using result. */
The latter case is better for applications that may want to perform
some other work before blocking on the result read().
The question probably is: Who's in the expected audience, or rather
which case is likely to be more common?
In other words: How often do you really need to perform work between
sending a query and reading its result?
I guess the answer depends on how many queries the programmer can "queue
up" (to be processed in parallel by the server).
Again, in general I prefer having the function tell me right there and
then what it will do.
If the blocking behavior of drizzle_query depends on some magic flag,
then I need to be hunting around for the call
setting the flag – which might be in a completely different file – and
need to look for later calls to drizzle_result_read.
What happens when someone changes the flag from non-blocking to blocking
behavior? Will the sequence
drizzle_query("SELECT 1", result);
drizzle_result_read(result);
still work? Or will it fail or corrupt result?
drizzle_result_read() will wait until drizzle_query() for that result
struct is ready to read. The purpose of the non-blocking
drizzle_query() behaviour/flag is for when you want to do *non-drizzle*
stuff after issuing drizzle_query(). At least, I *think* this is the
case :)
-jay
Having said that, I would prefer to have separate functions:
drizzle_query_async/drizzle_result_read and drizzle_query_sync (their
names are stupid and just for illustration purposes :))
That way there's no guessing and IMHO guessing is JustPlainWrong™ when
it comes to code.
cheers,
-k
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
