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 771828 - Missing methods in Type and missing TypeInterface
Missing methods in Type and missing TypeInterface
Status: RESOLVED FIXED
Product: vala
Classification: Core
Component: Bindings: GLib
0.32.x
Other Linux
: Normal normal
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2016-09-22 12:22 UTC by therebedragons111
Modified: 2017-02-14 08:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch adding the methods (4.31 KB, patch)
2016-09-22 12:22 UTC, therebedragons111
none Details | Review
fixed patch (4.31 KB, patch)
2016-09-22 14:35 UTC, therebedragons111
none Details | Review
gobject-2.0: Additions for ObjectClass, Type, TypeClass, TypeInterface (5.22 KB, patch)
2016-09-25 11:41 UTC, Rico Tzschichholz
committed Details | Review

Description therebedragons111 2016-09-22 12:22:54 UTC
Created attachment 336079 [details] [review]
patch adding the methods

Vapi file is missing some methods

This patch is addressing this issue
Comment 1 therebedragons111 2016-09-22 14:35:09 UTC
Created attachment 336085 [details] [review]
fixed patch
Comment 2 therebedragons111 2016-09-22 14:45:17 UTC
just to note that patch is still not finished as I am still testing it and making test case. but, if someone sees something wrong, please note the fact
Comment 3 Al Thomas 2016-09-22 15:41:20 UTC
Maybe:

 - git formatted patch
 - obsolete the old patch when uploading, just a bit easier not to make a mistake downloading the wrong one
 - TypeInterface and ObjectInterface should transform to type_interface and object_interface respectively, so I'm not sure lower_case_csuffix is necessary
 - Not sure why ObjectClass is a class, AFAIK a struct can also have a base struct, GLib.TypeClass in this case
 - I don't think there should be any void* return type in ObjectClass, these appear to be delegates. For more details on delegates in structs see https://mail.gnome.org/archives/vala-list/2016-September/msg00043.html and https://bugzilla.gnome.org/show_bug.cgi?id=659278 , but these could probably be bound similar to get_property and set_property
Comment 4 therebedragons111 2016-09-23 11:48:59 UTC
- that will come later
- obsolete where? I tried finding anything remotely similar to that when posting next patch but I couldn't find any action.
- What is ObjectInterface? If you mean equivalent to ObjectClass, then TypeInterface is it. As far as lower_case_csuffix, read next one
- Not sure my self. This is how Vala does it in parts I relied on for correct implementation. For starter I want to go with that and then after I sort out details work, then go in politics. This would most probably be its own bug
- Main problem is that even Gtk doesn't define other delegates as type. Only get_property and set_property. The rest are defined directly in ObjectClass and this is a bit of pain with how Vala processes it. It will stay void* until I create test case to be able to test it. Right now I only did that for Get/Set
Comment 5 Rico Tzschichholz 2016-09-25 11:41:50 UTC
Created attachment 336211 [details] [review]
gobject-2.0: Additions for ObjectClass, Type, TypeClass, TypeInterface

Based on patch by therebedragons111
Comment 6 Rico Tzschichholz 2016-09-25 11:58:05 UTC
Feel free to attach test-snippets for the new bindings to prove they are working.

How do you plan to use the exposed gobject delegate-fields? Those functions are created and bound by valac internally.
Comment 7 therebedragons111 2016-09-25 22:56:49 UTC
> Feel free to attach test-snippets for the new bindings to prove they are working.

That is something I want to do my self.

> How do you plan to use the exposed gobject delegate-fields? Those functions are created and bound by valac internally.

There are whole lot of uses mainly when you create runtime classes only that are created by application on the fly and on demand

Next, there are areas where Vala completely drops the ball and you can solve problems that way with a little reflection. For example, C generated from interfaces with DBus attribute (as well as its proxy class) is downright disaster. Both, interfaces and proxy class lose all the information about innards and to make it even worse they rely on methods that are completely out of scope from defined. This works when you use it from Vala, but if you want to do something that works everywhere...

Same thing goes for missing reflection properties. You can declare property of type MyStruct[], bool[] or any array except string for that matter, but again only accessible from Vala as it simply skips any install of these. The properties declared are dead in the water as they have get/set, but no information

Note that I am working patch for these issues (both of them), but first case is at least having full API for reflection.