On 08/30/2011 04:04 AM, Stefan Seefeld wrote:
On 08/30/2011 02:42 AM, Jim Bosch wrote:
On 08/29/2011 09:41 AM, Stefan Seefeld wrote:
On 08/28/2011 02:14 PM, Jim Bosch wrote:
To solve it, I think you'd want anything registered by a specific
module to appear both in that module's registry and the global
registry, with the module's registry taking precedence. Are there any
cases where you'd want something only to appear in the module-specific
registry?
Anything that gets injected into the global registry is prone to violate
the ODR. Of course, also adding it into a local registry and letting
that have precedence may mask the ODR violation issue. But in that case,
it isn't clear why we'd add it to the global registry at all.
The reason to add it to the global registry is so if you know one of
the modules you depend on registered a converter, you don't have to do
it yourself.
As I suggested in reply to Dave, I think it would be better to require
modules that depend on external converters to explicitly import them.
I can understand the motivation for requiring manual imports of
conversions, as a sort of "explicit is better than implicit" argument.
But I don't think it saves us anything in terms of ODR violations.
If I'm understanding the ODR issue (or lack thereof) correctly, we can
make everyone mostly happy by providing an option whether conversion
registrations should go into a per-module registry, a global one, or
both. We'd then allow modules to import the per-module registry of
another module into their own if they like. In all cases, we'd look up
things in the per-module registry first, and then go to the global
registry (where things registered by class_ would typically go).
I don't like the idea of Python users being able to tell all modules to
use a different set of conversions than the ones their authors intended.
That seems fraught with peril, and unnecessary if module builders can
pull converters from modules they depend on.
Jim
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
