Re: Re: Registries [2]

At 01:10 2003-07-28, David Abrahams wrote:
>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?

Yes it does, but:

    Converters are not associated with a lua state, so we don't
    necessarily have access to one at the import stage.

    There is no real standardized way of loading modules, so even
    if we could call a lua function that does the loading it doesn't
    mean we would call the right one.

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

Right, but this seems to imply the same implementation that I suggested.
Because even if module Y is initialized after module X, module X needs
to know about the converters module Y exposes. So the initialization of
module Y needs to add converters do module X's registry. Right?

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

No actually I meant what I wrote. :) I was talking about the 'module'
type in luabind, which is only a top-level alias for namespace_.

    module(L)
    [
       def("f", &f)
    ];

This places "f" in the global namespace. So what I'm saying is that
we can't use the name passed to module() as an identifier.

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

Ok. So in BPL the central registry could associate the extensions with
all the names of the modules it defines, right?

---
Daniel Wallin



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