Re: [pygccxml-development] FT -subst_t

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
> I don't understand why derived class code_manager_t should have ugly variable
> names: ARG_LIST_DEF,  ARG_LIST_TYPES and etc. This is not coding convention
> of Py++.

I was using upper case variables for sort of "low level" variables that
are usually initialized by corresponding lower case variables. From the
point of view of the function transformer class these variables can be
regarded as internal variables that the transformers usually don't get
in touch with.
But from the point of view of the code creator these are the variables
that it has to use for substitution.

> This class uses hard coded \n character. This is a mistake. It should use
>  os.linesep character.

Of course, I have no objections if you use os.linesep in your code, but
I just wanted to let you know that it doesn't really make a difference.
The following was executed in a Python shell under Windows:

>>> f=file("delme.txt", "wt")
>>> f.write("\n")
>>> f.close()
>>> file("delme.txt", "rb").read()
'\r\n'

Under Linux the same sequence would result in '\n'. So you see, at least
on Windows and Linux, the string "\n" is properly translated into a
native newline.

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
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. But 
on the other hand, adding it in pypp_api would probably also require 
some modifications in Py++ as it doesn't allow that sort of flexibility 
yet (maybe I could get around that and replace the code creator nodes 
after that tree has been built, but that would be less efficient than 
adding the right nodes right from the beginning...).

- Matthias -