Add optional parameter functionality to _WRAP_METHOD
Submitted by José Alburquerque
Link to original bug (#651523)
Description
Created attachment 188904 Patch to add optional parameter functionality to _WRAP_METHOD
While working on wrapping C functions I've seen that there always appear functions that accept optional parameters (passing NULL for them is acceptable in the C API). Often in the *mm module the overloads have to be written by hand and this can be time consuming. This patch modifies _WRAP_METHOD() so that it can recognize which parameters are optional and then generate all the overloads itself without the coder having to write the overloads him/herself.
The syntax is different, but I think it achieves the task. To specify if a parameter is optional the name of the parameter ends in '{?}'. For example by removing all the call_sync() method declarations and definitions in giomm's dbusconnection.{hg,ccg} and including the following wrap statement:
#m4 _CONVERSION(const Glib::VariantType&',
const GVariantType*',`$3.gobj()')
_WRAP_METHOD(
Glib::VariantContainerBase call_sync(const Glib::ustring& bus_name{?},
const Glib::ustring& object_path, const Glib::ustring& interface_name,
const Glib::ustring& method_name,
const Glib::VariantContainerBase& parameters{?},
const Glib::VariantType& reply_type{?}, GDBusCallFlags flags,
gint timeout_msec, const Glib::RefPtr& cancellable{?}),
g_dbus_connection_call_sync, errthrow
)
All the overloads are generated correctly in the .h/.cc files (I'll attach a patch to giomm's dbusconnection.{hg,ccg} with the wrap statement and the .h/.cc files so they can be seen).
What marks the optional parameters (as mentioned above) is the '{?}' following the name of the optional parameter, but the location and symbol can easily be modified. Further, if the patch proves to be useful, the _WRAP_CTOR and the _WRAP_CREATE macros can easily (after the patch) be extended to work in a similar way.
Also, adding the possibility to reorder the parameters and include an optional output parameter for _WRAP_METHOD is quite feasible (I have a couple of ideas that build on this patch). For example a parameter name can end in {num} to map that parameter with a specific C parameter (An optional ? after the number could still signify that the parameter is optional). As far as the optional output parameter, some M4 macros would have to be modified/added, but I've already got some ideas if that would make wrapping easier.
I think that if this patch is accepted, it would make wrapping C functions with optional parameters easier. It's about time wrapping is made a little more automatic, I think.
Patch 188904, "Patch to add optional parameter functionality to _WRAP_METHOD":
0001-gmmproc-_WRAP_METHOD-Add-optional-parameter-function.patch