GNOME Bugzilla – Bug 510453
Consider re-ordering cancellable arguments in async functions
Last modified: 2008-01-25 08:24:13 UTC
Many languages provide the ability to specify default values for function arguments, but require that arguments with default values be the last arguments in the function. It seems that it would be common for users of the gio library to not always use cancellable operations, so it seems reasonable to provide a default value of NULL for that argument. In gio, async operations require an async callback that is after the cancellable argument. Callbacks are by definition user-defined, so there is no way to make these have default arguments. It would give bindings more flexibility if the cancellable argument was the last argument in the function. In addition, it would be helpful if other arguments that could conceivably have default values (e.g. flags, io priority, etc?) could be placed at the end of the function as well. Of course, bindings could manually re-order arguments in order to be able to provide default arguments for some values, but it would be nicer to keep the argument order the same between the base library and the binding. This is not a big issue, but I thought I'd bring it up, since the C++ bindings are considering re-ordering the arguments, and other bindings may find it useful as well.
I also think that the callback should be before the cancellable, because the cancellable is more likely to be NULL than is the callback. In C++, for instance, we now have this: void unmount(SlotAsyncReady& slot, const Glib::RefPtr<Cancellable>& cancellable, MountUnmountFlags flags = MOUNT_UNMOUNT_NONE); void unmount(SlotAsyncReady& slot, MountUnmountFlags flags = MOUNT_UNMOUNT_NONE); void unmount(MountUnmountFlags flags = MOUNT_UNMOUNT_NONE);
Thats not a bad idea. However, its a lot of changes very late in the schedule, and its not a trivial fix to all the code using these either (i.e. you can easily miss some call and cause crashes at runtime).
(In reply to comment #0) > This is not a big issue, but I thought I'd bring it up, since the C++ bindings > are considering re-ordering the arguments, and other bindings may find it > useful as well. do you think you could provide a comprehensive patch for this soon? (so it still has a chance to get in before we freeze API/ABI)
I'm unconvinced about the feasibility of doing this api break this late in the cycle. A comprehensive patch would at this point have to cover the entire gnome 2.22 tree, since apps have started using gio already: eel, nautilus, gdk-pixbuf, epiphany...
As I said earlier, this isn't a big issue since bindings can work around it without too much work. I agree that it's a bit risky to change this late in the schedule since many of the arguments that would be rearranged are not particularly type-safe (gpointer and whatnot). I'm also quite busy lately so I'm unlikely to have time to patch all of the application using gio, especially if the patch wouldn't even be accepted by the maintainers. That said, If I get a definitive answer from the maintainers that this would be accepted, I will do my best to provide patches for gio itself whatever else I have time for.
I'd rather not. It seems to risky at this point.