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

[Roman Y. <rom...@gm...>]

On 9/7/06, Matthias Baas <ba...@ir...> wrote:
>
> 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?

No it is user API. Before applying some FT he can check whether it is
legal or not.

> - The code in signature_changes() looks brittle to me.

The code works only on function signature, as such it modifies the signature.

> 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.

Name is not important for return variable. The only important thing is the
number of return variables:
0 - void
1 - cpp type
1 < - 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.

singature_changes has nothing to do with function body implementation.
( I mean variables declaration )


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

No

> - 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?

Look we have problem, that your API does not solve it too:
sometimes user works on preparing call for Python, sometimes he works
on parsing Python tuple. API should stay explicitly what user works on.

> > I did not find better names. You are right - every transformation is a
> > function transformation.
>
>  From your definitions, it's the opposite...

No. Function transformation has different role: it provides an interface for
code creators.  Simple transformation has nothing to do with code creators

> > 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.

Yes it it. Because it provides different interface.


-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/