Introspection use cases

[Owen Taylor <otaylor redhat com>]

Some random thoughts of things we might want to do with the
introspection information when we have it.

Regards,
					Owen

* GUI builder

  - It should be possible to load up an arbitrary .so file
    into a GUI builder, find the widget (and other object)
    types in it, create them and manipulate them.

* "Libglade"

  - Should be possible to create a "libglade" equivalent that
    uses introspection information to locate _get_type() 
    functions.

* Dynamic language binding

- It should be possible to create a "good" language binding
   that works purely from introspection information.
      
   import gobject
   gobject.load_library("libgtk-x11-2.0.so.0")

   window = gtk.Window(gtk.WINDOW_TOPLEVEL)

   [...]

  Obviously, matching an existing API or writing language
  specific convenience functions would require custom glue.

- It should be possible to implement interfaces in dynamic 
  language bindings.

* Static language bindings.

- It should be possible to create a "good" language binding
  that creates a wrapper library in a compiled language completely
  from introspection information.

   $ gtkc++-compile libgtk-x11-2.0.so.0 -o libgtkc++-2.0.so.0.8.0 
     --include-output-dir=gtkc++

   #include <gtkc++/Window>
   
   [...]
    gtk.Window *w = new gtk.Window(gtk.WINDOW_TOPLEVEL);

  Obviously, matching an existing API or writing language
  specific convenience functions would require custom glue.

* Cross language interchange of objects

  It should be possible to create an object in language A, and use it
  from language B. (Activation is outside the scope of GObject, so
  say that the object already exists.)

  E.g., to write a FSpot (C# app) plugin in C, you'd first generate
  a wrapper library, then compile against that.

   $ gobject-wrapper fspot.xml -o libfspot.so.0 
    --include-output-dir=fspot

   #include <fspot/App.h>
 
   [...]

   FSpotApp *app = fspot_app_get(); // static method
   FSpotAlbum *album= fspot_app_get_album (app, 0); // method
  
  Obviously using arbitrary language features in the exported
  interfaces won't work, just as using arbitrary C won't work. But
  I think a limited subset is pretty easy to support.

  Also, arbitrary cross-language derivation is impractical, so
  interfaces that require subclassing must be avoided.

* Debug tools:

  - Having introspection information used by a debugger could
    be incredibly cool. Imagine being able to do:

    (gdb) call gtk_window_list_toplevels()

    And getting a list of GtkWindow *. If gdb was only more
    extensible...

- Could introspection information be combined with "sparse"
  to do static checking of code for memory leaks, etc?

  (More ambitious, use introspection information in a compiler
  frontend or preprocessor to optimize out runtime cast 
  checks)

- Could you do interesting things with introspection information
  from a valgrind skin?