After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 675295 - ability to rename or copy a method for g-i
ability to rename or copy a method for g-i
Status: RESOLVED OBSOLETE
Product: gobject-introspection
Classification: Platform
Component: g-ir-scanner
unspecified
Other All
: Normal enhancement
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
: 675297 (view as bug list)
Depends on: 684319
Blocks: 720090
 
 
Reported: 2012-05-02 13:49 UTC by Simon McVittie
Modified: 2018-02-08 12:14 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Simon McVittie 2012-05-02 13:49:12 UTC
It would be useful to be able to rename or alias methods in the g-i output.

Telepathy uses the same naming convention as GVariant/GValue, in which "get" means "don't copy" and "dup" means "copy", so we often get this situation:

* TpThing is an object

* tp_thing_dup_stuff() returns a copy of, or new ref to, a TpStuff

* tp_thing_get_stuff() doesn't exist, because we newly construct
  the TpStuff object on-demand, or because we want to be
  able to be thread-safe later, or whatever

It would be useful for Python/JS users to be able to call Thing.get_stuff() anyway, since they shouldn't need to care about the distinction between "borrow" and "copy" C semantics.

I tried to use "Rename to: tp_thing_get_stuff", but that annotation doesn't work (issues a warning and is ignored) when tp_thing_get_stuff doesn't exist. (Example diff and warning below.)

14:33 < walters> so...yeah the original use case for rename-to wasn't this, but 
                 we could probably make it work relatively easily
14:33 < smcv> walters: probably what we really want tbh is "Copy to"
14:34 < walters> right
14:34 < smcv> or /** tp_connection_dup_detailed_error: (introspect-as 
              get_detailed_error)
14:34 < smcv> or something
14:35 < smcv> g-i users shouldn't have to care about whether a function copies 
              its argument or not, but at the same time we like to make it 
              obvious for C users
14:36 < walters> the problem with rename-to is that it reveals our total lack 
                 of generated documentation that would help one understand 
                 "where did this C function go"
14:36 < walters> copy-to doesn't have that issue as much

-----

diff --git a/telepathy-glib/connection.c b/telepathy-glib/connection.c
index 53cb4b3..464f920 100644
--- a/telepathy-glib/connection.c
+++ b/telepathy-glib/connection.c
@@ -2880,6 +2880,8 @@ tp_connection_get_detailed_error (TpConnection *self,
  * Returns: (transfer full) (allow-none): a D-Bus error name, or %NULL.
  *
  * Since: 0.19.UNRELEASED
+ *
+ * Rename to: tp_connection_get_detailed_error_vardict
  */
 gchar *
 tp_connection_dup_detailed_error_vardict (TpConnection *self,


  GISCAN TelepathyGLib-1.gir
/home/smcv/src/fdo/tpglib/telepathy-glib/connection.h:175: Warning: TelepathyGLib: Can't find symbol 'tp_connection_get_detailed_error_vardict' referenced by Rename annotation
<unknown>:: Fatal: TelepathyGLib: warnings configured as fatal
<unknown>:: Fatal: TelepathyGLib: warnings configured as fatal
Comment 1 Colin Walters 2012-05-02 14:07:42 UTC
*** Bug 675297 has been marked as a duplicate of this bug. ***
Comment 2 Colin Walters 2012-05-02 14:08:14 UTC
Start of a patch in 675297, note the difficulty here is that it requires mutating the namespace as we're iterating over it.
Comment 3 Johan (not receiving bugmail) Dahlin 2012-05-02 14:44:17 UTC
That needs to be fixed either way, we should permit that new nodes are created/modified when iterate over a namespace.

I think the easiest solution is to just copy the namespace dictionary before iterating over it. However we may need to be a bit careful with new nodes as they need to be parsed in the same way as existing nodes.
Comment 4 Colin Walters 2012-10-26 19:15:32 UTC
I think I may have ended up implementing this in bug 684319
Comment 5 André Klapper 2015-02-07 17:17:43 UTC
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
Comment 6 GNOME Infrastructure Team 2018-02-08 12:14:59 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/67.