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 649548 - Full introspection/reflection API
Full introspection/reflection API
Status: RESOLVED WONTFIX
Product: vala
Classification: Core
Component: general
0.12.x
Other All
: Normal enhancement
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2011-05-06 09:56 UTC by Ricardo Gladwell
Modified: 2011-05-20 17:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Ricardo Gladwell 2011-05-06 09:56:57 UTC 
At the moment support for introspection relies on gobject-introspection. However, this API is only to provide metadata for public API/shared libraries to enable auto-generated bindings and does not support:

  1. executable programs
  2. nested namespaces

It would nice to have full, native support for introspection/reflection in Vala ala Java and C# reflection.
Comment 1 Jürg Billeter 2011-05-20 17:05:48 UTC 
GObject introspection should work fine for applications as well, as far as I know. GEdit uses it. I don't intend to start my own introspection/reflection API for GObject-based libraries just because GObject introspection does not currently support nested namespaces.
Comment 2 Ricardo Gladwell 2011-05-20 17:08:15 UTC 
It's not just for support of nested namespaces, but also for non-shared libraries like executable programs.

Reflection is a powerful tool for modern languages, and has many useful applications wrt attributes, it would be a shame not to see this in Vala. Please reconsider closing this defect.
Comment 3 Jürg Billeter 2011-05-20 17:10:32 UTC 
(In reply to comment #2)
> It's not just for support of nested namespaces, but also for non-shared
> libraries like executable programs.

Where do you get the idea that GI does not work for applications? GEdit uses GI just fine, as far as I can tell.
Comment 4 Ricardo Gladwell 2011-05-20 17:12:56 UTC 
Isn't GObject-Introspection's focus narrower than providing general metadata?
Reading around the subject, it seems it's to provide metadata for public
API/shared libraries to enable auto-generated bindings which is why, as I understand it, it doesn't support executable libraries. Valac won't generate GIR data for executable libraries AFAICT.
Comment 5 Ricardo Gladwell 2011-05-20 17:13:53 UTC 
See this discussion for more information:

http://mail.gnome.org/archives/vala-list/2011-April/msg00105.html
Comment 6 Ricardo Gladwell 2011-05-20 17:14:36 UTC 
"executable libraries" above should read "executable programs".
Comment 7 Jürg Billeter 2011-05-20 17:20:48 UTC 
There might be bugs/missing features in this area in Vala and/or GObject Introspection, however, I don't see a fundamental reason why we couldn't improve these components to provide a full introspection/reflection API. GI can definitely already be used for classes that are just in the program and not in any library. If there are specific issues in Vala and/or GObject Introspection, we should work on these and not start from scratch on a second implementation.
Comment 8 Ricardo Gladwell 2011-05-20 17:24:47 UTC 
I'm not sure that that GI can definitely already be used for classes that are just in the program, that seems to contradict what I've read on the subject. I'm sceptical that the GIR people would ever be willing to modify their API, seeing as they don't see it being used for anything except to enable auto-generated bindings. Especially given their reasons for rejecting support for nested namespaces:

https://bugzilla.gnome.org/show_bug.cgi?id=576327