Re: Re: Registries [2]

At 20:41 2003-07-26, David Abrahams wrote:
>Daniel Wallin <[email protected]> writes:
> >  >> How about "explicit is better than implicit"? ;) Seriously, isn't it
> >  >> a good thing to be able to control which converters are imported?
> >  >> To remove possible collisions.
> >
> >  >Yes.  I believe you should be given that control.  That's no reason
> >  >not to share automatically when no explicit importing has been done.
> >  >Backward-compatibility is also a good thing, and writing less code is
> >  >a good thing.  When you don't need explicit control (e.g. because
> >  >you're working on a closed system) it might be enough.
> >
> > Right, how about:
> >
> >    Automatically import converters for all types in the local
> >    converter registry.
> >
> >    Explicit always overrides implicit, so if a local converter
> >    is registered, all implicitly imported converters are
> >    thrown out. They are also thrown out if converters are
> >    explicitly imported.
>
>On a type-by-type basis?  There's no need to do that; you just make
>the implicitly imported converters lower-priority (keep them at the
>end of the chain).  I wouldn't want to disable an implicitly-imported
>Python tuple -> C++ vector<double> converter just because there was an
>explicitly-imported Python list -> C++ vector<double> converter.

I guess you are right. I was thinking that there might be some interest in
removing converters from the chain, perhaps to keep the number of converters
down. This could be interesting if we were to try all converters and choose the
best matching converter. Perhaps we should only apply best match to overload
resolution though, and just consider first matching converter as best match.
It can't be very common that several converters can convert from the same
source object anyway.

> >    Collisions in the to_xxx converters are handles by just
> >    setting the function pointer to 0, indicating that explicit
> >    importing is needed.
> >
> > And a note on the implementation; is initialization ordering of
> > extensions an issue here?
>
>I guess it might be.  What do you have in mind?

What I wrote below, cyclic dependencies.

> > Is it common to have cross dependencies?
>
>I think it probably happens occasionally, though not often.
>
> > If that is the case, converters need to be added to the local
> > registry from the outside. So when saying "import converters from
> > module X" we are really saying "when module X adds a converter to
> > it's local registry, add it to mine as well".
>
>I don't think we have to get that fancy.  We can just
>initialize module X if it isn't already, and then import all the
>converters that it has registered.  I'm not too worried about
>supporting dynamic registration of converters after module
>initialization time.

Right, or rather; demand that the user initializes module X before.
This doesn't play well with automatic importing though.

>Hmm, if there was really a mutual dependency we might have an issue,
>but we could still handle it with a simpler mechanism that simply
>deferred imports until initialization was completed.

I guess, but it would be nice to handle it without introducing code in
the dispatch functions. Which is the only place I can think of where
we could defer importing to.

> > How are extensions to be registered in this central registry? In my
> > previous post I proposed that they should be registered with a
> > string literal identifier.
> >
> >    register_extension("my_extension");
> >
> > How does this fit in with pythons module system? (Note that we are
> > really registering the extension, and not modules).
>
>Every extension is a module (not nececssarily the other way around),
>so I see no reason not to register the extension by its module name

I guess in python you can ask the interpreter state for the current module 
name?
In lua this isn't possible though, so we would need some user defined 
identifier instead.
---

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