Registries [2]

At 01:52 2003-07-25, David Abrahams wrote:
 >Daniel Wallin <[email protected]> writes:
 >> At 00:09 2003-07-25, David Abrahams wrote:
 >>>Daniel Wallin <[email protected]> writes:
 >>>
 >>> > Hi David,
 >>> >
 >>> > I'm just checking if you are actually receiving my mails on the
 >>> > list, once again it's been two days since my last post. I understand
 >>> > you might be very busy, but still we could benefit from a little
 >>> > pace in the discussions. :)
 >>>
 >>>Maybe I'm not!  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.

 > This was my response:

 >>  >> Just did, this seems to imply that we can actually have a local (to the
 >>  >> extension) registry and share converters by explicit import, as 
previously
 >>  >> suggested, is this correct?
 >>  >
 >>  > I guess so.  I don't see any great reason not to share automatically
 >>  > as well, as a fallback.
      ^^^^^^^^^^^^^^^^^^^^^^
 >So you did get a response from me after all?

Hm, yes. On the first post that you missed.

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

   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? Is it common to have cross dependencies?

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

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

 >> Also, for which case is sharing automatically a fallback?

 >For the case where no explicitly imported (or locally generated)
 >converter is available.

 >That said, if we can convince Ralf that explicit whole-module
 >converter importing is enough, I'm all for throwing out automatic
 >sharing.

Ok great.

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