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.

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?

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
--
Kay Roepke
Software Engineer, MySQL Enterprise Tools

Sun Microsystems GmbH    Sonnenallee 1, DE-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer:    Thomas Schroeder,  Wolfang Engels,  Wolf Frenkel
Vorsitz d. Aufs.rat.: Martin Haering                    HRB MUC 161028


_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help   : https://help.launchpad.net/ListHelp

Reply via email to