Re: Registries

Daniel Wallin <[email protected]> writes:

> At 17:32 2003-07-16, David Abrahams wrote:
>>Daniel Wallin <[email protected]> writes:
>>
>> > At 15:38 2003-07-15, David Abrahams wrote:
>> >>Daniel Wallin <[email protected]> writes:
>> >>
>> >>I'm not really sure it amounts to much.  The additional complication
>> >>should go into the *registration* process instead of the lookup
>> >>process, to make sure that lookup stays fast.
>> >
>> > Right... How would these scopes be specified by the user?
>> > What constitutes a scope?
>>
>>I don't think the user would specify scopes explicitly, except to
>>import from them.  They'd follow the nested structure of modules
>>precisely, and the user would use module names to refer to them.
>
> Could you explain more how the modules would nest, 

I don't understand the question.  Python has module (package)
hierarchies, so a top-level module foo might have a sub-module foo.bar

Users can create submodules by sticking them in a package hierarchy,
or by opening a new module scope with 

   module('bar') [ ... ] 

if we accept the luabind syntax.

> and how would the scoping "just work"?

Types and converters registered in a sub-module would be propagated up
to the registries of the sub-module's ancestor modules.

They will be looked up on a first-registered, first-found basis.

It's beginning to sound a bit complicated, so I'd really like to hear
from Ralf whether explicit imports would be so bad.

> How does a module know it's parent?

Well, in Python the full module path is in m.__name__ for any module
m.  It might be 'mypackage.mysubpackage.mymodule'

>> > Ok, there are two use cases:
>> >
>> >    Build you module as a shared lib and expose some function
>> >    that binds all your C++ code to the lua state. There are
>> >    some fairly standardized symbol names that are used for this
>> >    (luaLM_version, luaLM_import).
>>
>>So this function goes into lua's global namespace and is called
>>explicitly by the user to load the module?  It sounds a bit like the
>>module init function used by python.
>
> Well, there are different ways of handling this.. Lua has a built in function
> that loads a function from a shared library. Used like this:
>
>    local init = loadlib("mymodule.dll", "init_mymodule")
>    init()
>
> there's at least one extension that allows:
>
>    loadmodule("mymodule.dll")
>
> which I guess is almost equivalent to:
>
>    function loadmodule(name)
>      local init = loadlib(name, "luaLM_import")
>      init()
>    end
>
>>Does the shared lib get opened with dlopen, thus ensuring link symbol
>>isolation from other modules?
>
> Yes, at least that's what I concluded after investigating the source to some
> of the loaders.
>
>> >    Bind your module directly to the interpreter by modifying the lua
>> >    state:
>> >
>> >      lua_pushstring(L, "my_fun");
>> >      lua_pushcclosure(L, &my_fun, 0);
>>
>>How does the code which does the binding get invoked?
>
> Either by doing it in a function that's exposed from a shared lib

That's the same as the first case, right?

> or by just invoking it. :)
>
>    int main()
>    {
>      lua_State* L = lua_open();
>      lua_pushstring(L, "my_fun");
>      lua_pushcclosure(L, &my_fun, 0);
>      ..
>    }

You can't "just invoke it" from Lua, so you must be talking about
embedding Lua in another app in this case.

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