On 10/05/2011 07:21 AM, Dave Abrahams wrote:
on Tue Sep 20 2011, "Niall Douglas"<s_sourceforge-AT-nedprod.com> wrote:
On 19 Sep 2011 at 17:03, Jim Bosch wrote:
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.
Surely not! You'd want to let template specialisaton be the first
point of call so the compiler can compile in obvious conversions,
*then* and only then do you go to a runtime registry.
I don't understand why you guys would want compile-time converters at
all, really. Frankly, I think they should all be eliminated. They
complicate the model Boost.Python needs to support and cause confusion
when the built-in ones mask runtime conversions.
I have one (perhaps unusual) use case that's extremely important for me:
I have a templated matrix/vector/array class, and I want to define
converters between those types and numpy that work with any combination
of template parameters. I can do that with compile-time converters, and
after including the header everything just works. With runtime
conversions, I have to explicitly declare all the template parameter
combinations I intend to use.
This also lets one override the runtime registry when needed in the
local compiland. I'm not against having another set of template
specialisations do something should the first set of specialisations
fail, and/or the runtime registry lookup fails.
There are better ways to deal with conversion specialization, IMO. The
runtime registry should be scoped, and it should be possible to find the
"nearest eligible converter" based on the python module hierarchy.
I think this might turn into something that approaches the same mass of
complexity Niall describes, because a Python module can be imported into
several places in a hierarchy at once, and it seems we'd have to track
which instance of the module is active in order to resolve those scopes
correctly.
I do hope that most people won't mind if I don't implement something as
completely general as what Niall has described - there is a lot of
complexity there I think most users don't need, and I hope he'd be
willing to help with that if he does need to deal with e.g. passing
callbacks between multiple interpreters. But I'm also afraid he might
be onto something in pointing out that fixing the more standard cases
might already be more complicated than it seems.
Jim
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
