Re: Registries

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?

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

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

> > void init_my_module()
> > {
> >    register_module("my_module"); // register this modules conversion
> >    registry in
> >                                                  // the shared library
> >    using_module("second_module"); // import entire module
> >    using_<A>("third_module"); // import one type
> >
> >    module(..)
> >    [
> >      class_<B, A>("B")
> >    ];
> > }
> >
> > That would mean we wouldn't have any central converter registry at
> > all, but rather a central registry of converter-registries.
>
>I want to make the functionality you cite above available even if we
>have scopes, so yes, we would need that regardless.

Ok.


> > This makes the system sensitive to ordering though, but I don't know
> > if that's really an issue.
> >
> >>P.S. Are lua extensions built as shared libs?
> >
> > Well, there isn't any standardized extension system. But I think
> > there are some third party code that allows you to load a module
> > from a shared library with a function call from lua. I blame this
> > for my lack of knowledge on shared libraries. ;-)
>
>I think it's really important that you find out how people operate
>before we go much further.  We have to know what the important use
>cases are.

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


   Bind your module directly to the interpreter by modifying the lua
   state:

     lua_pushstring(L, "my_fun");
     lua_pushcclosure(L, &my_fun, 0);

I would think both are equally important.

---
Daniel Wallin



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1