GNOME Bugzilla – Bug 736441
Printing a socket address is too complex
Last modified: 2018-05-24 17:01:08 UTC
logging a simple message like "Connected to 123.123.123.123:42" requires *a lot* of boring code: - from the connection you get the GSocketAddress - you cast GSocketAddress to GInetSocketAddress making an ugly assumption - from the GInetSocketAddress you get the GInetAddress - GInetAddress finally has a to_string() method that just gives you the IP part - the you get the port from the the GInetSocketAddress - then you strdup_printf the two GSocketAddress should have a print method that 1) takes care of all this stuff for me 2) does not require to assume that it can be casted to a specific subclass I guess (2) requires adding a vfunc implemented by the subclasses
(In reply to comment #0) > - you cast GSocketAddress to GInetSocketAddress making an ugly assumption Well, you generally know that it's a GInetSocketAddress. But it might be a GProxyAddress, which is a subclass of that, but in that case you might want to show both the proxy address and the final destination. > I guess (2) requires adding a vfunc implemented by the subclasses which unfortunately we can't do, because many of the networking-related classes accidentally got added without extra padding in their class structs.
Some ideas, none particularly clean: 1 - add a display-name property and override it in the subclasses instead of the vfunc 2 - (ab)use g_signal_new_class_handler to add an overridable vfunc 3 - hardcode a "case IS_INSTANCE_OF ()" in the base class for the known subclasses and just print "unknown" for the rest, since subclassing is pretty rare
(In reply to comment #2) > 1 - add a display-name property and override it in the subclasses instead of > the vfunc That's probably the cleanest, and you can provide a wrapper method to fetch it, in which case it looks just the same as a vmethod from the caller's point of view.
Adjusting component to gio in preparation for GitLab migration
-- 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/glib/issues/926.