Jim, My answer for 1), 2) for module specific behavior would be that I would probably not use module specific behavior. In my current project I separate the code into multiple BOOST_PYTHON_MODULE. So I would want to use project specific behavior and not behavior specific to the BOOST_PYTHON_MODULE. I could reorganize the code, but I kind of like the idea of separating the big python module into several sub-modules. As for project specific behavior, I would actually want 2) always, and I would want 1) optionally. So I would like to enable or disable 1) either in the build tool or with some global python variables. As for 3) I would prefer the exact match from the global registry. I assume that this case would appear if a user overloads a function from python. -Holger On Mon, Sep 19, 2011 at 23:03, Jim Bosch <talljimbo@gmail.com> wrote:
I'd like to restart the discussion on how conversions will work in Boost.Python v3. Here's the starting point:
I'd like to see support for static, template-based conversions. These would be defined by [partial-]specializing a traits class, and I tend to think they should only be invoked after attempting all registry-based conversions. Users would have to include the same headers in groups of interdependent modules to avoid specializing the same traits class multiple times in different ways; I can't think of a way to protect them from this, but template-based specializations are a sufficiently advanced featured that I'm comfortable leaving it up to users to avoid this problem.
We've had some discussion of allowing different modules to have different registries (in addition to a global registry shared across modules). Leaving aside implementation questions, I have a little survey for interested parties:
1) Under what circumstances would you want a conversion that is completely limited to a specific module (or a group of modules that explicitly declare it)?
2) Under what circumstances would you want a conversion to look in a module-specific registry, and then fall back to the global registry?
3) Considering that we will have a "best-match" overloading system, what should take precedence, an inexact match in a module-specific registry, or an exact match in a global registry? (Clearly this is a moot point for to-Python conversion).
Finally, can anyone give me a reason why having a global registry can lead to a violation of the "One Definition Rule"? This was alluded to many times in the earlier discussion, and there's no doubt that a global registry may lead to unexpected (from a given module's perspective) behavior - but I do not understand the implication that the global registry can result in formally undefined behavior by violating the ODR.
Thanks!
Jim _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig