Re: Registries [2]

Daniel Wallin <[email protected]> writes:

> At 01:52 2003-07-25, David Abrahams wrote:
>  >Daniel Wallin <[email protected]> writes:
>  >> At 00:09 2003-07-25, David Abrahams wrote:
>  >>>
>  >>>I turned off mail delivery and started using gmane.
>  >>
>  >> I'm curious, what's the benefit of that? Better threading?
>
>  >Less crap in my inbox.  Plus they keep a permanent archive.  Plus
>  >it's faster than my IMAP server ;->
>
> Ah.. My main concern with reading news is that I have yet to find a client that
> suits me.

A lifelong quest for me as well.  Right now I'm using GNUs for
integrated mail/news; for me it's the least of all evils (but not by
much).

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

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

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

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.

> 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


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



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