Re: Registries

Daniel Wallin <[email protected]> writes:

> At 15:38 2003-07-15, David Abrahams wrote:
>>Daniel Wallin <[email protected]> writes:
>>
>> > Sounds good. But is it really necessary to have outward searching, or even
>> > scopes at all? Can't we just have a flat hierarchy of modules that always
>> > need to explicitly import types from other modules?
>>
>>Well, I'm not dead-set against it but there are 2 problems:
>>
>>1. Backwards compatibility: currently all modules in Boost.Python just
>>    share automatically.  This would force everything to be explicit.
>
> Sure, although it's probably really minor changes to the module source.
> Other changes that might come from this project will perhaps break things
> way more, don't you think?

I hope not.  Well, the policies syntax might change a bit, but I
believe it's possible to provide backward compatibility if we care to.

>>2. We had something similar in BBv1 and my CBD guys in Ralf's group
>>    report a *big* usability improvement in BBv2 from the automatic
>>    sharing.  Of course, you had to name every type being shared
>>    explicitly in that case.
>
> Right, it would probably be less of an improvement if you could
> import entire modules. I would like to hear what Ralf says about
> this though.

Me too. Ralf?

>> > It would simplify converter lookup a great deal.
>>
>>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.

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

Does the shared lib get opened with dlopen, thus ensuring link symbol
isolation from other modules?

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

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