Re: Registries [2]

Daniel Wallin <[email protected]> writes:

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

Seriously?  Lua doesn't give you everything you need in order to
invoke lua code, including code which would load a module?

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

Oh.  The implicit imports I thought we'd handle by having a global
converter registration chain for any type and simply tacking it onto
the end of each extension's local chain as part of the initialization
of the local registration.

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

See above.

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

Yep, seems so.  But I don't have a strong preference.

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

Likewise Python.

> and also unnamed modules which are placed directly in the global
> namespace.

Err, I think you mean "extensions not associated with a module which
place their definitions into the global namespace", right?  What is a
module, after all, if not a 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.

Fine, we can do that in the core if you really perceive an advantage
(though I question whether the flexibility is worth the complication).
It would seem perverse for the Python layer to do anything other than
lock the name of an extension to the name of its module.

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

I think I just said that too ;->

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



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