Re: Introspection API

[Maciej Katafiasz <ml mathrick org>]

Dnia 25-02-2005, pią o godzinie 14:38 -0500, Colin Walters napisał:
> >> > IMHO, strings are not good enough. Annotations should be real type,
> >> > similar to objects (but simpler), with parameters and inheritance.
> >> 
> >> Well, I'm not sure this is really worth it. Do you have any concrete use
> >> cases in mind, or is this just general nonsense, 'but Java5 has it'
> >> stuff ?
> >
> >Some major use cases:
> >
> >1) Serialisation (ie, autogeneration of DBUS bindings for GObjects)
> 
> Can you be clearer here?  Serialization of what exactly?  The whole idea
> with GObject introspection (excluding annotations) by the way is that
> autogeneration of D-BUS bindings is much cleaner and easier.

I know that DBUS is one of bigger users that are guaranteed to make use
of introspection the day it lands in HEAD :). Serialisation as in
marking interfaces which are supposed to be serialised, ie. prepared for
use over IPC, like .NET's SerializableAttribute, serving as hint for
runtime that you intend to use that class for remoting. Then you can
tweak parts of class with more hints, like tag given method as internal
and what have you.

Some examples showing that structured information can indeed be put to
good use:

http://www.ondotnet.com/pub/a/dotnet/2003/07/28/understadingattributes.html

> >2) Unit tests (you can mark functions that are tests to be run, and
> >expected outcome)
> 
> I don't see why you need anything other than strings for this; just have
> a standard annotation named org.gtk.GLib.Test with a value "true".

http://www.nunit.org/exception.html -- notice that what's passed in is
type, not string, so you can manipulate it right away without fiddling
with (de)serialising to stringified version.

> >3) Annotations for language bindings, to tweak some things which were
> >previously done by overriding .defs (of course, the ideal case is when
> >everything works automagically, but it's imperfect world, and we should
> >be prepared)
> 
> This might be a better argument, but someone familiar with language
> bindings would have to give specific examples of data that couldn't be
> fairly cleanly mapped to a string.

I'd envision things like mapping types (python's dict vs. glib's hash
table), where being able to express things in structured way would
de-uglify the process a lot.

> >4) Custom, app-specific tagging of stuff. It's not absolutely necessary
> >when we have g_object_set_data(), but still useful to be able to tag
> >entire type.
> 
> Can you give an example of when you'd want to do this?

http://www.ondotnet.com/pub/a/dotnet/excerpt/prog_csharp_ch18/index.html?page=2#cust_attr

Again, you could do everything with strings only (after all, you can
serialise everything to string, as shown by Serializable attribute :),
but it gets ugly quickly. Kinda like not having recursive types in
GConf, forcing everyone to come up with their own serialisation scheme
when storing more complex data. You can get around this, but it's simply
not pretty, and rather cumbersome.

Cheers,
Maciej

-- 
Maciej Katafiasz <ml mathrick org>