|
From: Roman Y. <rom...@gm...> - 2006-09-05 13:10:16
|
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. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Matthias B. <ba...@ir...> - 2006-09-05 16:53:00
|
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. I couldn't follow all of the argumentation that is done in the first part, but as it was already your own conclusion that this would lead to a design that is too complicated anyway I don't think we have to discuss this any further, except for the things that also appear in the second part. I don't understand the rationale behind the separation into "transformation" and "function transformation" (by the way, it's also a bit unfortunate that they both use almost the same name. And sometimes the name "transformer" is used). Your definition of "transformation" doesn't separate it from "function transformation", so from reading the definitions it seems that "function transformation" is just a special case of a "transformation", i.e. one that is created by doing a composition of several transformations. But the result of doing this composition is still in compliance with the definition of "transformation". The section about function transformations in the second part of the document suggests that this class is just an internal helper class for the object that manages the application of the individual transformers. It seems that this class is neither directly used by the transformation objects nor by the actual code creators that use this service. The document is not yet detailed enough to get an overview on how the transformation process is done, so I can't comment on that one. From looking at the interface of transformer_t alone I can't see how it works, and the interface of the substitution manager is not given (but obviously it has to be different than in my implementation). Maybe an example would be helpful (e.g. how the "output" transformation would look like). - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-09-05 18:14:08
|
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. > > I couldn't follow all of the argumentation that is done in the first > part, but as it was already your own conclusion that this would lead to > a design that is too complicated anyway I don't think we have to discuss > this any further, except for the things that also appear in the second part. It was important for me to see "the right" solution. After this I was able to estimate your solution. > I don't understand the rationale behind the separation into > "transformation" and "function transformation" (by the way, it's also a > bit unfortunate that they both use almost the same name. And sometimes > the name "transformer" is used). > Your definition of "transformation" doesn't separate it from "function > transformation", so from reading the definitions it seems that "function > transformation" is just a special case of a "transformation", i.e. one > that is created by doing a composition of several transformations. But > the result of doing this composition is still in compliance with the > definition of "transformation". I did not find better names. You are right - every transformation is a function transformation. Obviously the composition of transformations is still a transformation. May you can suggest a better name? > The section about function transformations in the second part of the > document suggests that this class is just an internal helper class for > the object that manages the application of the individual transformers. > It seems that this class is neither directly used by the transformation > objects It should not be used by transformation object, the opposite is right. >nor by the actual code creators that use this service. Right now, but I propose to change this. > The document is not yet detailed enough to get an overview on how the > transformation process is done, so I can't comment on that one. From > looking at the interface of transformer_t alone I can't see how it > works, and the interface of the substitution manager is not given (but > obviously it has to be different than in my implementation). Maybe an > example would be helpful (e.g. how the "output" transformation would > look like). Do you want to discus this on IRC? -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Matthias B. <ba...@ir...> - 2006-09-07 12:29:08
|
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 - |
|
From: Roman Y. <rom...@gm...> - 2006-09-07 18:09:55
|
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/ |
