Re: [pygccxml-development] function transformation - design & implementation

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

Roman Yakovenko wrote:
> On 9/5/06, Matthias Baas <ba...@ir...> wrote:
>> Roman Yakovenko wrote:
>> > Hi. Finally I reviewed Matthias design and implementation. I propose
>> > to make some changes
>> > in its implementation. I described my thoughts in the document.
>> > 
>> http://svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/docs/peps/function_transformation.rest?view=markup 
>>
>> > Comments are welcome.

Now that the output_arg_t example is available I have some more comments:

- Is the check() method also used outside the class? The example 
suggests that it is only supposed to be used internally by 
signature_changes(). But if signature_changes() has to call that method 
explicitly anyway then why is it part of the public API?

- The code in signature_changes() looks brittle to me. It requests an 
operation to remove an argument and then another operation to add a 
variable with the same name as the removed argument to the result tuple. 
  But this looks somewhat illogical to me because the variable that is 
added to the result does not exist at that time, it was just removed by 
the previous operation. So this code depends on another operation 
(namely that a variable with a particular name gets added again) which 
is located in a separate method that is executed sometime later. But who 
guarantees that a variable with this name can actually be added at that 
later time? What if another transformer has already added a variable 
that incidentally used the same name?

- In apply() there's the line "sm. add variable to return expression". 
Isn't that the same as was already done in signature_changes()?

- In the "else" block of the apply method: How does the method know 
which item of the tuple it has to access? How does it obtain the name of 
the argument? Which part of the code specified that the extraction code 
has to be put after the wrapper function call?

- Obviously, apply() is called twice and receives different instances in 
"sm". It seems as if *every* implementation of apply() will require the 
if...else construct. So why isn't the method split into two methods then?

> I did not find better names. You are right - every transformation is a 
> function transformation.  

 From your definitions, it's the opposite...

> Obviously the composition of transformations is still a
> transformation. May you can suggest a better name?

I think all is said by mentioning that transformations can be 
composed/concatenated. I don't think this requires a special name.


- Matthias -