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.
Indeed, I never understood that myself. At the Python/C++ language
boundary there is no such thing as "compile-time".
>> 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.
...combined with some hints users can add to their modules. Again, I
think we should favor explicit conversion policy settings over implicit
ones.
Sorry, I haven't yet managed to find time to sketch this out in any
detail. I hope to be able to do that to help with this project, though.
Thanks,
Stefan
--
...ich hab' noch einen Koffer in Berlin...
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
