GNOME Bugzilla – Bug 710583
g_dbus_connection_call_with_unix_fd_list_finish and g_dbus_proxy_call_with_unix_fd_list_finish don't follow standard async method argument ordering
Last modified: 2013-10-22 20:41:24 UTC
g_dbus_connection_call_with_unix_fd_list_finish and g_dbus_proxy_call_with_unix_fd_list_finish don't follow the standard async method argument ordering which is (object, result, return values, error). i.e. GVariant *g_dbus_connection_call_with_unix_fd_list_finish ( GDBusConnection *connection, GUnixFDList **out_fd_list, GAsyncResult *res, GError **error); should be: GVariant *g_dbus_connection_call_with_unix_fd_list_finish ( GDBusConnection *connection, GAsyncResult *res, GUnixFDList **out_fd_list, GError **error); This causes the Vala bindings for GLib to incorrectly call g_dbus_connection_call_with_unix_fd_list_finish as it assumes the second argument is the GAsyncResult. I don't know if other bindings have the same problem. I'm not sure if there's an appropriate solution for this without creating new method names, but I'm looking for a solution in GLib and/or Vala.
vala is clearly already looking at the introspection data, since it knows that the out_fd_list arg is there at all, so it ought to just be paying a bit more attention... Having inconsistent style is bad, but I'm not sure it's so bad that we'd actually want to deprecate and redo the function...
Vala bug is bug 688907
I don't think there are any "standard async method argument ordering". I think the problem is that Vala is making incorrect assumptions - all it needs to know should be in the gir/typelib; if it isn't, the Vala people needs to work with the GI people to expand the format.
Yeah, agreed about the severity. I thought it best to raise a bug so at least it can be found if others come across it and we have a decision on it.
for what it's worth, I winced when reading the API at the top of this bug. This is definitely a violation of my expectations, but that said, I don't think we can reasonably fix it at this point.
so, wontfix ?