Re: Adding full introspection information (#139486)

[Maciej Katafiasz <mnews22 wp pl>]

Dnia 04-11-2004, czw o godzinie 18:47 -0500, Havoc Pennington napisał:
> Some small thoughts:
> 
>  - your goal 1 of no hand-coded elements in bindings I think has 
>    problems with current gtk. The APIs are too inconsistent, and 
>    many of them don't use gobject (structs, etc.)
> 
>    So you're expanding the scope of the problem 
>    from "be able to introspect APIs that use gobject and 
>    follow some clear guidelines" to "be able to introspect
>    arbitrary C, arbitrary API conventions, etc."

Well, yes, but I hope that at least getting it to "custom struct of size
X" level should be good step ahead. If we can get to the point where
arbitrary (or "arbitrary enough", there are many things that are
possible to do, but aren't used in GObject-using APIs, we only need to
support the common cases anyway) APIs can be described, that's even
better, but not strictly necessary to get that 80% Just Working(TM)

>    We could get useful introspection for dbus with *much* 
>    less work, because really all that matters is objects
>    that are explicitly designed for remoting.

I guess so, but 1) DBUS is much less general case than GObject is, so
benefits are also smaller 2) This has really kinda different scope, we
want to get rid of notion of "bindings" altogether (not counting generic
bindings for GObject itself of course), thus radically changing
development process and opening up whole slew of possibilities 3) In the
end, we will need GObject bindings to allow nice "make me DBUS object
out of this GObject" API anyway :)

>    Question: are *any* of the current language bindings
>    100% autogenerated? I think all of them hand code a 
>    lot of things, even the ones that autogenerate most 
>    of the GObject wrappers.

No, currently they are hand-written in large part. Generating bulk code
from .defs is step one, writing manual overrides for places needing
special attention (which currently are numerous, due to the lack of
enough info in .defs, which stems from lack of enough info in code /
markup) is second

>  - I think matching CLR/JVM is not really the goal; rather, 
>    the goal should be exporting our C APIs to those.
>    The "future of runtimes" or "future object system" should 
>    be the CLR/JVM object type, not GObject.

Yes, and having GObject that Just Works(TM) with these is great step
towards any of them (although I still think there's no reason to ditch
GObject once it gets complete enough, if you can get to write code in
Python, _and_ have it work with CLR/JVM for free, _and_ choose not to
use any if you so desire, then what else do you need? :)

>  - on naming schemes: this is another argument for saying that
>    only APIs designed to be introspected are introspected, 
>    because you could enforce particular naming guidelines
>    on introspectable API
>    Alternatively, allow override of the native<->binding
>    identifier mapping on an identifier-by-identifier basis

Yes, that will definitely need to have its place in typelib, every piece
of GObject code should be clearly marked with namespacing info, which
will then serve to construct native names, so that

namespace "Gtk" {
class "Widget" {
method "show_all";
};
};

should end up as gtk_widget_show_all() in C, gtk.Widget.show_all() in
Python, and Gtk.Widget.ShowAll() in C#. Fortunately, this should be easy
enough to get to work (almost) 100% automatically, since that's
basically what happens today, and transformations are mostly mechanical
-- there's script that reads .defs and generates names following the
native conventions for given bindings

>  - a requirement I think you missed is small size and speed,
>    it needs to be relatively unbloated. Qt redid their typelibs
>    in Qt 4 to avoid problems here. Essentially have only one 
>    or 2 object file symbols per GObject for the typelib.

I don't think there should be much overhead there, mostly it should
incur only one-time penalty when reading the info for the first time, as
after that wrapper objects are generated and thunks written so that all
goes through normal calling mechanism. Also, using clever enough scheme
for that (ELF sections on *nix), we should be able to reduce additional
symbols resolved at link time to not more than few of them, maybe even 0
(dunno how exactly ELF linker treats that). And even in less flexible
object formats, we still can get away with exactly one additional
symbol, something like __gobject_typelib_info which will then point to
everything else that's needed.

> Anyhow, I would argue for KISS; we don't need the ultimate object
> system, and I'd also punt on automatic language bindings for all of
> glib/pango/gtk. We just need a simple way to write automatically
> remotable/bindable objects, which probably allows us to *mostly*
> automate the language bindings.

Well, in the case of language bindings, there's very big difference
between "99.999% automated" and "100% automated and the very moment you
write it". The difference is not only the time when you're able to use
the bindings, it totally changes the way you can use your code. Similar
to the famous Paul Graham's quote:

"Imagine the kind of conversation you would have with someone so far
away that there was a transmission delay of one minute. Now imagine
speaking to someone in the next room. You wouldn't just have the same
conversation faster, you would have a different kind of conversation. In
Lisp, developing software is like speaking face-to-face. You can test
code as you're writing it. And instant turnaround has just as dramatic
an effect on development as it does on conversation. You don't just
write the same program faster; you write a different kind of program."

Bindings that happen automatically allow you to differently structure
your program, to pass different things between languages. You just can
do things that aren't possible when you need separate process of
generating bindings

Cheers,
Maciej

-- 
"Tautologizm to coś tautologicznego"
   Maciej Katafiasz <mnews2 wp pl>
         http://mathrick.org