Re: Introspection

[Maciej Katafiasz <ml mathrick org>]

Dnia 11-01-2005, wto o godzinie 17:14 +0000, Mike Hearn napisał:
> On Tue, 11 Jan 2005 05:12:51 +0100, Maciej Katafiasz wrote:
> > > * The metadata should be stored as a binary blob in the library.
> > >   one idea for finding the metadata is to use a symbol name  
> > >   derived from the module name, e.g. the metadata for GTK+ would
> > >   be accessible via a symbol like _GTK_METADATA. Using a fixed
> > >   symbol name would be problematic when using dlsym() to find
> > >   the data. 
> > 
> > I think we should use common interface for accessing that data, which
> > would be then implemented using specific mechanisms. For ELF .so, we
> > could just use private section or something like that. For python it'd
> > be something created as we go through code, and then merged with rest of
> > metadata. There still remains question of activation method though, see
> > below.
> 
> I think the only feasable way of doing this is to have a dedicated ELF
> section. This is complex but the best way forward:
> 
> - Variables in ELF ABIs are bad bad bad due to the screwball way ELF is
>   designed. Basically if you refer to that variable in a module the size
>   of that data is encoded in your binary and a difference in size 
>   will cause the linker to bail out.

Totally funky.

>   I guess it you never actually refer to it anywhere except via dlsym
>   it might work. But people would ... and then they'd get bitten
> 
> - A function that returns the data is the most obvious way forward from
>   here but how do you share the possibly large data between processes?
>   It has to have some relationship to a disk file for mmap sharing to work.
> 
> - Hence, an ELF section: can be any size, can be mapped and therefore
>   shared
> 
> > Activation and cross-references are going to be tricky, to say the
> > least. How do we activate referenced types written in Python? How far
> > are we going in support for activating unregistered types? Is
> > registering it enough provided we can find it in current metadata repo,
> > or is loading .so still in order? I suspect that in order for this to
> > stay sane and flexible enough, we will need to move quite a bit of
> > responsibility to bindings, and hide that behind pretty interfaces.
> > Whatever we do, we should avoid solutions like hardcoding sonames for
> > example, if at all possible.
> > 
> > @Mike Hearn: how does COM do it?
> 
> I'm not sure what you're asking here. For activation COM maps globally
> unique IDs to DLL names which are expected to export magic symbol names
> that when given a COM class ID returns a constructed version of it (kind
> of, skipping class factories here). So the actual location of code doesn't
> matter too much as there is this additional indirection.

Hmm, so you're supposed to have function with magic name constructible
from CLSID that when called does the right thing and makes it so that
afterwards everything is in place and we can construct objects of given
type right away? Did I understand it right?

/me tries to map that concept to Python and Guile...

Cheers,
Maciej

-- 
Maciej Katafiasz <ml mathrick org>