Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:19 PM +0100 1/4/04, Leopold Toetsch wrote:
>>Its a bit complicated and brain-mangling, the more in the absence of
>>any examples, but the current design in pdd16 seems to lack some
>>flexibility and is IMHO missing the proper handling of the
>>(library-provided) external_data. The latter will be passed to the
>>Sub somehow, but what then?
> Well...
> The current system's simple on purpose, because making sure all the
> possible callback function signatures are supported would just be a
> massive pain in the neck.
> Before we go extend things any more, let's get the current system
> fleshed out some (heck, let's get it working!)
I've now implemented that as far as pdd16 goes. It requires one more step
(as already proposed in the previous f'up in this thread):
new_callback P5, P6, P7, "tU" # Z in pdd16
This constructs a callback PMC P5 from Sub P6 and user_data P7. The
actual callbacks signature is "xU" for callback_C or "Ux" for
callback_D. The signature char 'x' can be currently any of the integer
types or 't'. So we have a notion for the external_data we get passed on
in the callback.
This separate step seems to be necessary anyway, because the NCI
function could await that callback embeded in some structure, so we can't
always pass it on directly, like pdd16 does.
The signature type for the callback ('C' in pdd16) isn't currently
needed, the 'p' type is used instead. And I've used 'U' for user_data
not 'Z' like in pdd16.
Almost all other constraints from pdd16 are still true:
- the callback must pass on one void* user_data transparently
- the CB takes exactly 2 params, castable to void*
Finally getting a callback asynchronously isn't a problem, because
callbacks are run via the event system.
Do we still need the "do it all at once" shortcut from pdd16?
leo
