Re: Registries

At 18:54 2003-07-16, David Abrahams wrote:
>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.

Oh ok, I wasn't aware of how Pythons module system works. So when
you import a submodule, the parent module is automatically loaded as well?

Anyway, this means the scoped converters would be python specific, or at 
least not
supported by lua. (since lua doesn't even have modules in the python sense).

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

Ok.

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

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

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.

Yeah, to clarify: Most common usage is to just embed lua in your app and
export your bindings directly to the lua state. I don't think it's very common
to use lua as a standalone interpreter, although people probably do that as
well.

---
Daniel Wallin



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0