Stewart Smith wrote:
> On Mon, 2008-08-04 at 10:54 -0400, Jay Pipes wrote:
>> -1
>>
>> I would prefer not to get into the game of the plugin developer having
>> to know a different function for each type of plugin they develop. Just
>> do something like krow suggests with a base class inheritance:
> <snip>
>> That way, plugin developers just call a single register_plugin()
>> function and the kernel takes care of allocating/assigning the passed-in
>> pointer to the appropriate HASH of plugins for that plugin_type...
>
> supporting C only plugins is a good thing though, so requiring C++ may
> not be the best thing... although....
Just to be devil's advocate... the whole server codebase (drizzled/*
subtract sql_state.c and stacktrace.c) is .cc files... (won't claim it's
solid C++, but still...) is there really a benefit to pure-C plugins?
> struct plugin {
> enum plugin_type type;
> union {
> struct function func;
> struct engine engine;
> }
> };
>
> could work....
I would really rather have the struct of function pointers than the
thing above... Why? Because I would eventually love to be able to do
plugins in not C or C++ (python, etc) and mapping unions of structs to
any language that isn't C is a real pain (mgmapi has one of those
constructs, and it gives me hives)
> but the benefit of having method-per-plugin type is that we get type
> safety checking by compiler, and can have plugins just in C.
And compiler safety checking is a good thing. I like the method per
plugin idea, myself... I don't think it's any tougher if all of the
registration methods are in a different place.
(Just as long as we aren't casting function pointers to (char *) and
then sticking them in a struct with a Type enum, I'm great, really)
Monty
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
