Re: Introspection API

[Maciej Katafiasz <ml mathrick org>]

Dnia 25-02-2005, pią o godzinie 10:59 -0500, Matthias Clasen napisał:
> > >From what Mike said, referencing any variable in ELF means instant ABI
> > breakage, since somehow linking to variable relies on its size. Should
> > change that to private ELF segment, or better yet, just say it's detail
> > and up to implementation (as on Win32 for example you can't add
> > arbitrary segments to PE, from what I know)
> > 
> 
> Oh, this is certainly meant to be an implementation detail, not part of
> the API. The library-side api to this stuff should be the 

Ah. That wasn't entirely clear from spec.

> g_irepository_register   (const guchar *metadata);
> g_irepository_unregister (const guchar *metadata);
> 
> functions which were included in the repository API draft sent out
> earlier. I would envision the metadata compiler to emit a C file
> containing _init and _fini functions calling the above functions.
>
> I have currently no idea how ELF sections work. How does that work
> practically ? Is it portable ?

I think every platform using ELF supports them, but I don't know that
for sure. Mike?

> > > Types are specified by two bytes. If the high byte is zero, the low
> > > byte 
> > > describes a basic type, otherwise the 16bit number is an offset
> > > relative to 
> > > header->types and points to a TypeBlob. 
> > 
> > Hmm, so we will need to always pad first 255 bytes in header->types,
> > because no TypeBlob can point to anything below 256 byte, right?
> > 
> 
> Yes, the first 255 bytes after the location pointed to by header->bytes
> are not usable for types. I was envisioning to just let header->bytes 
> point 255 bytes "too low", if you care about the little wasted space.

Ok, I was just confirming it wasn't overlooked or misinterpreted on my
end.

> > Are we we going to only ever need numerical values? What about other
> > types? Or did I misinterpret something?
> > 
> > If not, I'd propose layout like this (less compact, but we won't be
> > storing millions of consts in metadata I suppose):
> > 
> 
> Well, not millions, but GTK+ has certainly a non-neglegible number of 
> enumeration values.

Hmm, right.

> > struct ValueBlob
> > {
> >   guint16 type;  /* 9 */
> >   guint   deprecated : 1;
> >   guint   reserved   :15;
> >   guint32 name;
> > 
> >   guint32 short_name;
> >   guint32 value_length;
> >   guint16 type; /* TypeBlob */
> >   guint8 value[]; /* Interpret according to type */
> > }
> > 
> 
> Ok, I clearly overlooked the fact that we may want to allow non-numeric
> constants. To explain how this happened: ValueBlob was originally only
> for enumeration/flags values, where only numerical values make sense.
> Then Michael Meeks pointed out the need to describe constants, so I
> thought allowing values outside of enumerations would take care of that.
> 
> Maybe we should have a separate ConstantBlob including type information.

That was the other idea I had. Probably we should go with separate
EnumValueBlob and ConstantBlob, as use cases are different enough to
warrant existence of two types.

> > On related note, it would be probably useful to be able to get
> > non-function C symbol names, wouldn't it? So slam additional symbol_name
> > in above struct. In case C symbol is there, we also want to avoid
> > specifying value ourselves (length == 0), to keep metadata and actual
> > value seen by C code in sync.
> 
> What would you use it for ? The symbol names are necessary to look up
> the functions, and the type names are necessary to look up GTypes. But
> I don't see a real use for symbol names here, unless you want to
> describe exported variables, which I had not in mind at all.

Yes, that was partly my intention. Don't we ever export const int foo =
5; or anything similar?

> Another possible reason to include C names would be if we wanted to 
> be able to regenerate the headers from the metadata, but I'm not sure
> that is really worthwhile or practical.

We want to be able to regenerate headers if we are to allow GObject
libraries implemented in languages other than C. While outside of scope
of metadata spec, IMHO format of metadata shouldn't preclude writing
library that would deal with seamless activation of non-C code one day.

> > > Up to 16bits of padding may be inserted between the arrays to ensure
> > > that they start on a 32bit boundary.
> > 
> > How do we detect that is the case? And will 32bit be sufficient
> > alignment on all archs?
> 
> You just count the bytes from the beginning of the InterfaceBlob, which
> is known to be on a 32bit boundary. E.g. if the number of interfaces is
> odd, there will be padding between interfaces[] and values[].

Oh. Again, that wasn't entirely clear from spec, including the
explanation above should clear any doubts.

> "Sufficient" for what ? It may not match the natural struct layout on 
> the platform, but it is enough to be able to read the values from the
> blob as guint32. If a guint32 value is straddling a 32bit boundary, it
> may be necessary to read it as to guint16 and reconstruct it manually
> on some platforms.

"Enough" as in not cause SIGBUS while reading it. But if we read it as
guint32, then I guess 32bit padding ought to be enough.

> > Minor nitpick, I'd rephrase it as: "An array of direcory indices
> > pointing to the implemented interfaces for objects, and to prerequisites
> > for interfaces."  Besides, it's confusing to use "interface" for both
> > GInterface and metadata interfaces.
> 
> I'd be happy for better naming proposals. 

Hmm, maybe "entry"?

> > 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)

2) Unit tests (you can mark functions that are tests to be run, and
expected outcome)

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)

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.

In each case, having typed, structured data instead of strings is much
cleaner than just null-terminated strings.

Cheers,
Maciej

-- 
Maciej Katafiasz <ml mathrick org>