GNOME Bugzilla – Bug 562498
fundamental types for gint16/guint16 missing
Last modified: 2015-03-09 17:08:14 UTC
It seems GObject lacks fundamental types for gint16 and guint16, e.g. G_TYPE_INT16 G_TYPE_UINT16 This is a shame because it makes it hard to map IPC protocols (like D-Bus) with these types onto the type system (simply mapping it to G_TYPE_INT/G_TYPE_UINT throws away information). I will attach a patch that introduces these types along with other support infrastructure like pspec etc.
Created attachment 123575 [details] [review] proposed patch I'm not sure all the the value transform stuff is needed. Please advise. Thanks.
See bug 158818 for an earlier attempt in this direction...
Another one is bug 554482
*** Bug 554482 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > It seems GObject lacks fundamental types for gint16 and guint16, e.g. > > G_TYPE_INT16 > G_TYPE_UINT16 TWithout loss, tese can already be represented with G_TYPE_INT and G_TYPE_UINT respectively, in combination with a GParamSpec that has value ranges of -32768..32767 or 0..65535. Introducing extra types for 16 bit ints wouldn't have any additional benefit, it'd just bloat logic in all current generic type system API users (language bindings, serialization interfaces, etc).
(In reply to comment #5) > (In reply to comment #0) > > It seems GObject lacks fundamental types for gint16 and guint16, e.g. > > > > G_TYPE_INT16 > > G_TYPE_UINT16 > > TWithout loss, tese can already be represented with G_TYPE_INT and G_TYPE_UINT > respectively, in combination with a GParamSpec that has value ranges of > -32768..32767 or 0..65535. Introducing extra types for 16 bit ints wouldn't > have any additional benefit, it'd just bloat logic in all current generic type > system API users (language bindings, serialization interfaces, etc). It is wrong that there is no added benefit. Without G_TYPE_INT16, a function like this can never ever work DBusMessage *serialize_gvalue_to_message (const GValue *value); since it's not possible to for that function to figure out whether it should serialize @value into a 16-bit integer or 32-bit integer on the wire. Neither will gboolean serialize_message_to_gvalue (DBusMessage *message, GValue *value); work; the user has no chance in hell to figure out whether he got a 16-bit or 32-bit integer back. This is not all theoretical, if you care about serialization you want e.g. the user to be able to pass collections (e.g. hash tables, lists) annotated with the type serialize_hash_table_onto_message (DBusMessage *message, GHashTable *hash, GType key_type, GType value_type); or whatever (could use the Map type from libgee for example). So I think it is a serious problem with the type system if it doesn't know about fundamental types; it essentially makes stuff like that really weird (it is not at all reasonable for a library to register fundamental types). Reopening. And if you close it again, at least close as WONTFIX, not NOTABUG.
Also, wondering how you'd expect people to use glib-genmarshal for projects that invent their own 16 bit types.... right now I have to copy those sources into my D-Bus code generator...
Created attachment 131941 [details] [review] missing pieces for the proposed patch This feature is also important for Telepathy's use of D-Bus, so we would like to see it merged. This patch is a follow-up to davidz's proposed patch. It adds the v_int16 member to the _GTypeCValue union, some tests, and updates gobject.symbols. It should probably be merged with the original patch davidz proposed. make check passes.
Created attachment 137714 [details] Add 16-bit signed and unsigned integers to GLib. This takes the two patches already attached to the bug and cleans up some whitespace issues in the first one. I have tested these patches and they work well in my testing (to test, I added proper support to Vala [patch forthcoming on related bug] and used the test case that caused me to stumble upon this bug in the first place). These patches should apply to the git repository with 'git apply'. If there are any issues, please let me know. I would really like to see these patches get in soon so that there is a good chance of these patches landing for glib 3.0.
Comment on attachment 137714 [details] Add 16-bit signed and unsigned integers to GLib. Hrm. Unticked the patch box, as it was screwing with the MIME type. Can resubmit as concatenated text files as well, if that works.
Created attachment 137717 [details] [review] Add 16-bit signed and unsigned integers to GLib. My apologies, I totally don't know how to use git. This one should *actually* contain the patch.
Created attachment 137718 [details] [review] Actually add 16-bit signed and unsigned integers to GLib. Oops, attached the wrong patch last time. Sorry for all the extra noise, I am an idiot. :-/
Hey, are there plans to get this in soon? The patch should be pretty straight-forward to review, I guess. Any thing I could do to help there?
Is there a way to request a review outside of the bug tracker?
(In reply to comment #6) > It is wrong that there is no added benefit. Without G_TYPE_INT16, a function > like this can never ever work > > DBusMessage *serialize_gvalue_to_message (const GValue *value); > > since it's not possible to for that function to figure out whether it should > serialize @value into a 16-bit integer or 32-bit integer on the wire. Neither > will That's abusing the type system. To know details about any particular value/proeprty, libgobject provides paramspecs. If you want your above function to handle type details beyond GLib fundamental type information, such as value ranges, default values, integer bases, float epsilons and whatnot, simply add paramspecs to your API (or use your own metainfo system). The fundamental type system is intentionally as lean as possible (module historical baggage) because it's types are supported with lots of extra code in many different programs/libraries (particularly language bindings). At this point we're only going to extend the fundamental types if new C types come along that can't be represented with the existing infrastructure (e.g. a 128bit wide long or similar extensions for doubles).
(In reply to comment #15) > (In reply to comment #6) > > It is wrong that there is no added benefit. Without G_TYPE_INT16, a function > > like this can never ever work > > > > DBusMessage *serialize_gvalue_to_message (const GValue *value); > > > > since it's not possible to for that function to figure out whether it should > > serialize @value into a 16-bit integer or 32-bit integer on the wire. Neither > > will > > That's abusing the type system. To know details about any particular > value/proeprty, libgobject provides paramspecs. I don't understand; GValue doesn't allow one to reference a paramspec, unless I'm missing something?
Thank you timj for your help! what's the difference between having it in glib or having it in, let say, gdbus (or something like that) ? Bindings that do not want to or can't support this type can't skip it if it's in glib? Sorry, I just want to understand better. also, I suppose that a basic type that exists in dbus should be fairly bindable in different language. But maybe I misunderstand the situation. thanks again
(In reply to comment #15) > The fundamental type > system is intentionally as lean as possible (module historical baggage) because > it's types are supported with lots of extra code in many different > programs/libraries (particularly language bindings). But increasingly we'd like to emphasize bindings based on the GNOME platform, rather the two best examples are JavaScript and Vala, the latter is in fact explicitly designed for GObject. So if say Vala had a gint16 type, it would certainly be better if it had an explicit GValue type as well.
Whoa. What happened here? Why has this been marked resolved? Is there some problem with providing gint16/guint16? Is there a problem with the patches? Is something else the matter?
(In reply to comment #18) > So if say Vala had a gint16 type, it would > certainly be better if it had an explicit GValue type as well. It has. It seems the Tim Janik (developr) marked bug as NOTABUG. What's strange as far as I understend there exists developers which does not share his view (including reporter). The main argument is that it can be easily created. However (reading only bug) those projects have separate G_TYPE_SHORT/INT16/... (list may be out-of-date) - gtkmm - gdbus (isn't some of dbus going to be integrated into glib? how is that resolved?) Also it seems that those 'should' have: - vala
(In reply to comment #18) > So if say Vala had a gint16 type, it would > certainly be better if it had an explicit GValue type as well. It has. ---- It seems the Tim Janik (developr) marked bug as NOTABUG. What's strange as far as I understend there exists developers which does not share his view (including reporter). The main argument is that it can be easily created. However (reading only bug) those projects have separate G_TYPE_SHORT/INT16/... (list may be out-of-date) - gtkmm - gdbus (isn't some of dbus going to be integrated into glib? how is that resolved?) Also it seems that those 'should' have: - vala
I think this is the kind of thing that will keep burning cycles, and causing discussion for quite a bit. It's obviously something many people need, and would like to have from a central place instead of reinventing the wheel. It's not too hard to keep this code maintained. I do wonder why we don't just get these kinds of trivial stuff done with, so we can stop arguing about them, and waste less time doing unnecessary work. By the way, from the email with subject 'GLib plans for the next cycle' that Matthias Classen sent early this year: "- What do we do about the added 16bit integer types that are supported by the DBus protocol, but don't have corresponding fundamental types in GObject ? EggDbus currently has fundamental types for them. My proposal: Just add the fundamental types to GObject. It would be odd to ship fundamental types spread over several libraries, and int16 is really not worth fighting against..." http://mail.gnome.org/archives/gtk-devel-list/2009-February/msg00039.html
I know it's really important to some people to have, and that there isn't any reason I can think of that would block its addition. I can see reasons against having 128-bit and 256-bit integers, since those would be slow on just about every single imaginable current platform. As I've mentioned in the past on this bug report, I'm willing to respond to feedback on the attached patch, if someone is willing to provide the feedback so that any necessary issues can be addressed before the code is integrated into the VCS tree. I'd like to make it as close to a zero-effort integration for the maintainer as possible, so that this issue can just quietly be fixed for the next release.
... Could someone at least change the resolution to WONTFIX?