Re: pre-summit introspection status



Colin Walters wrote:
> For those not tracking Planet, here's a pre-summit status report on
> introspection:
> 
> http://cgwalters.livejournal.com/21209.html
> 
> Feedback I think would be most helpful is on the annotation syntax,
> and more eyes checking coverage in gir-repository and filing bugs for
> the things we're doing wrong.

I have a comment on annotation syntax.  I don't like that the annotations are
in comments.  In Berlin I suggested to Johan that something like Qt's "slots"
trick can be used.  That is, preprocessor macros that normally expand to
nothing, but the scanner defines them to something special.  Then one could do
things like:

/**
 * gtk_list_store_set_column_types:
 * @store: a #GtkListStore
 * @n_columns:
 * @types: <array,length=n_columns>: List of types
 */
void
gtk_list_store_set_column_types (GtkListStore *list_store,
                                 gint          n_columns,
                                 GType        *types G_IR_ARRAY
G_IR_ARRAY_LENGTH(n_columns));



Johan didn't see any immediate benefit in that and suggested that it makes for
a worse syntax and formatting, and I agreed.

But most recently I was reading the static analysis literature and came across
the idea of using gcc user-attributes for source code annotation.  Take the
above example, then one can define:

#define G_IR_ARRAY __attribute__((user(g_ir_array)))

On the face, it's not much different from what I proposed earlier.  However,
it has an immense power: you can use gcc or gcc-compatible frontends.
Moreover, you can write static analyzers that check, for example, that the
array is not shorter than its claimed length.  The possibilities are uncountable.

If you don't like the syntax, it can be done on the prototype like, much like
G_GNUC_PRINTF stuff:

void gtk_list_store_set_column_types (GtkListStore *list_store,
                                      gint          n_columns,
                                      GType        *types)
G_IR_ARRAY(types, n_columns);

So, here I am proposing it.  Recently some guys at Google used that format for
thread-safety static analysis.  See:

  https://docs.google.com/View?docid=ddqtfwhb_0c49t6zgr


Cheers,

behdad


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]