Matthias Baas wrote:
>As to the rest of your mail, I'd rather like to begin at the top instead
>of the bottom and see if we can get to a consensus about the API that
>function transformer classes can access. From all your mails about the
>topic I take it that the function transformer functionality as you have
>it in mind is quite a bit different than what I have implemented. So I
>started adding sort of a tutorial that explains how function
>transformers are written:
>
https://realityforge.vrsource.org/view/PyppApi/WritingCustomFunctionTransformers
Thank you for the document, now I understand better your idea.
>This is what a user has to know if he wants to write his own transformer
>classes using the current implementation (the tutorial is not exhaustive
>though). I have added two example classes that demonstrate some parts of
>the API. I'm assuming that the reader also has a look on the
>corresponding parts in the epydoc manual. If the interface as it is seen
>by the user would be kept intact then, of course, I wouldn't mind if the
>underlying implementation is modified.
>
>By the way, my current situation is that the current version of Py++ can
>almost do everything I wanted to have for the Maya bindings
>(unfortunately, I have just noticed that there actually are some pure
>virtual methods in the Maya SDK, so that's what's still missing for me
>to do another release). So during the last week I could actually
>continue developing the bindings which unfortunately left me with less
>time for Py++ (the last couple of changes have just been
>bugfixes). In addition to that, meanwhile we have a new version of Maya
>and creating the bindings for the new version has highlighted some other
>problems with Py++ (namely getting an overview of the differences
>between the versions and the generated bindings) which might lead to
>some modifications to pypp_api.
>Now I'm not sure if I should add the code creator for pure virtual
>members to the existing code (using the existing "implementation
>scheme") or to pypp_api. Knowing that the implementation won't survive
>anyway in function_transformers I'm a bit reluctant to add it there.
I want to make it clear: your idea will stay but implementation will
be slightly changed. I think we can do all changes I want in a week
or two.
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
