GNOME Bugzilla – Bug 774647
Wrong function names in Gio::Settings - set_enum(), set_flags() mistyped as get_enum(), get_flags()
Last modified: 2016-11-30 16:40:38 UTC
settings.hg: https://git.gnome.org/browse/glibmm/tree/gio/src/settings.hg#n155 > _WRAP_METHOD(int get_enum(const Glib::ustring& key) const, g_settings_get_enum ) > _WRAP_METHOD(bool get_enum(const Glib::ustring& key, int value), g_settings_set_enum) > _WRAP_METHOD(guint get_flags(const Glib::ustring& key) const, g_settings_get_flags) > _WRAP_METHOD(bool get_flags(const Glib::ustring& key, guint value), g_settings_set_flags) The problem is pretty obvious: the attempts to wrap these set_thing() methods are typo's as get_thing(). This makes these functions unusable from the API - unless the user were to deliberately use the wrong names and thereby render their own code incomprehensible. :P
Created attachment 340186 [details] [review] patch: fix the wrapped method names (and remove one unnecessary space)
I do agree, this should be fixed.
Yes. I wonder if we should deprecate the old methods while adding the new ones. Or do we say that they so obviously wrong that nobody could possibly be using them.
(In reply to Murray Cumming from comment #3) > Yes. I wonder if we should deprecate the old methods while adding the new > ones. Or do we say that they so obviously wrong that nobody could possibly > be using them. That's what I thought; probably nobody's used it so far, otherwise I assume he'd report the bug. I think we could safely remove this API.
I'm also guessing no one used the wrongly named methods, as they would've realised the problem and reported it, but I guess I'm the first pioneer who's using this piece of GSettings in glibmm! Haha. I think anyone using such opposite method names in live code, with no notice or care for the semantics, is probably overdue for their app to break slightly. ;)
The supplied patch shall obviously be pushed to the ABI/API-breaking master branch. As for the glibmm-2-50 branch it's safer to add correctly named methods, but keep and deprecate the incorrectly named ones. But must we be that safe?
Any more thoughts on whether this will be pushed to master and (hopefully!) 3-22?
I have pushed your patch to the master branch, and a similar one to the glibmm-2-50 branch. The 2-50 patch keeps and deprecates the misnamed methods.
Thanks a lot!