Re: Introspection

[Maciej Katafiasz <ml mathrick org>]

Dnia 11-01-2005, wto o godzinie 17:48 +0000, Mike Hearn napisał:
> > 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...
> 
> No, it's simpler than that.
> 
> 1) You call  CoCreateInstance( {some-com-128-bit-id} );
> 
> 2) COM looks that ID up in the registry which says "This object
>    can be found in foobar.dll", so it dlopens foobar.dll and grabs
>    the DllGetClassObject function, then calls it with that ID
> 
> 3) Your object implementation provides that function and hands back
>    a class factory, which COM then uses to manufacture an object instance
> 
> No magic function name construction is needed because PE doesn't have a
> stupid linking model that causes symbols to conflict.

Well, in theory ELF doesn't either, at least AFAIK, it's only flaw in
ld-linux.so or something related.

Anyway, I'm trying to fit that somehow into dynamic languages situation,
and not sure, but it might be doable. If we supply .so with entry point
that imports appropriate python (guile, perl, etc.) module, creates
metadata subtree for GObject types from it, then merges with rest of
metadata repository, we're basically set. The only big problem is -- how
do we do that *without* resorting to broken schemes a'la registry which
would map GTypeName <-> dll? I refuse to use registry for my GObjects,
that's for sure.

Answer 1:
We don't, and instead require app to have everything loaded but maybe
types not necessarily registered, then process of activation is in fact
registering all the parent types down to requested one, using info that
is already in repo. But the basic problem is still there, we don't
really have languages swappable, and app linked against, say, GFooType C
implementation residing in libgfoo.so can't transparently go for
python-based one, unless it replaces entire libfoo.so with magic .so
that will know to load gfoo.py. Similarly app using
libmagicpythonloader.so to obtain GFooType implementation couldn't
easily get it from libgfoo.so... Dunno how much of hot-swap is doable
and feasible, but I'd like to have as much as possible. And certainly
term "DLL Hell" gets entirely new meaning when you take into account
that apps can use not only different versions, but also entire language
runtimes depending on when and how they were linked.

Answer 2:
1. Get requested type name
2. ?????
3. Load type definition from correct .so entry point which will by then
know what exactly is needed to do that
4. PROFIT!

Free beer for anyone who figures out step 2

Cheers,
Maciej

-- 
Maciej Katafiasz <ml mathrick org>