[C++-sig] [Boost.Python v3] Features and Scope
Jim Bosch
talljimbo at gmail.com
Tue Aug 30 20:06:50 CEST 2011
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
More information about the Cplusplus-sig
mailing list