Re: Re: Registries [2]

At 15:43 2003-07-27, David Abrahams wrote:
>Daniel Wallin <[email protected]> writes:
>
> >> > Also, at least in lua. Modules could be loaded at any time, so there 
> isn't
> >> > really a point where we can assume everything is loaded and import
> >> > converters.
> >>
> >>Can't you do something similar to the above?
> >
> > I don't think so. When I said "at any time" I didn't mean concurrently.
> > Consider (lua code):
> >
> > loadmodule "X" -- exposes f(std::vector<double>)
> > loadmodule "Y" -- exposes some convenience converters
> >                 -- lua -> C++ std::vector<double>
> >
> > We would really like for module X to be able to use the converters
> > introduced by module Y here, but module X is already initialized
> > when module Y's converters are created.
>
>The way I envisioned it:
>
>     module X is loaded; loading_count = 1
>
>     module X's initialization function imports converters from module
>     Y, which causes Y to be loaded and initialized

This might be possible in python, but we can't generally force another
module to load. At least it isn't possible for luabind.

Also, note here that module X wasn't importing converters from module Y.
They were to be imported implicitly.

>     loading_count = 2
>
>     Y registers its converters
>
>     if Y imports converters from X, we notice that X is currently
>     being initialized, and we push the request on a queue
>
>     Y's initialization completes; loading_count = 1
>
>     X registers its converters
>
>     X's initialization completes; loading_count = 0
>
>     Because loading_count = 0, we look at the import request queue
>     and find the X->Y request.  We satisfy that.

This is fine for explicit importing, given that we can force a module to 
load, but
what about implicit importing?

This is my way:

    module X is loaded (meaning it's luaLM_import or whatever function is 
called).
    module X calls a central registry saying "hey, here's my converter 
registry,
    associate it with this name".

    module Y is loaded.
    module Y adds some converters to it's local registry. This results in 
the central
    registry going through all other converter registries, and exports the 
added converters
    to those.

Is this really more complex?

> >> >> > In lua this isn't possible though, so we would need some user defined
> >> >> > identifier instead.
> >> >>
> >> >>You've gotta have the module or its name stored somewhere, dontcha?
> >> >
> >> > Other than in the .so filename? No.
> >>
> >>Why not just store it then?  When you create it, stick a string in its
> >>__name__ attribute.
> >
> > I don't know what this means, create what? And what string? And how?
> > :)
>
>When you create the module, stick the name of the module in its name
>attribute, e.g.
>
>struct lua_module : lua_object
>{
>    lua_module(char const* name)
>    {
>         ...
>         this->attr("__name__") = name;
>         ...
>    }
>};

Right, module's in luabind isn't really like modules in python.
It's possible to have multiple "modules" per extension, and also  unnamed
modules which are placed directly in the global namespace.

I think I would like to keep the extension identifier separate from the 
identifiers
the user may or may not use for their modules.

It seems to me that this could be handled differently in bpl and luabind 
though, as
long as we share the underlying technology for importing/exporting.

>Also, take a look at the BOOST_PYTHON_MODULE macro.

Ok.

---

Daniel Wallin



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01