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 <tallji...@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 > _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
