|
From: Roman Y. <rom...@gm...> - 2006-09-21 18:10:56
|
On 9/21/06, Matthias Baas <ba...@ir...> wrote:
> > Yes of course. First of all I committed new version that should fix the
> > problem.
>
> No, it doesn't (because now the class mem_fun_transformed_wrapper_t is
> not instantiated).
I am sorry I break it. For my defence I can say that I run
function_transformation
unit test and it passed.
Also if mem_fun_transformed_wrapper_t is not instantiated, than
find_out_mem_fun_creator_classes is broken and we should fix it.
> Unfortunately, I also have to say that I'm not that happy about the
> workaround to force the generation of a wrapper class. This is a step
> back from what was already there. The comment you put into the code
> ("function transformers require wrapper") is not true. The majority of
> classes in the Maya SDK (which do use function transformers) do not
> require a wrapper class and I'd like to keep it that way. To quote yourself:
>
> "The generated code should not be too different from the one, that human
> would write. I don't write code like this."
Actually I do.
When we discussed this feature I explain why I prefer to keep wrappers and
ask you explicitly to create generated code in a wrapper.
> I know that for some reason you do want to have wrapper classes in all
> cases. That's why I would have added an option to control this.
Please don't. This is not an option that should exist. Someday we will fix the
problem in the whole project.
> Actually, we could have reused an option that was already there once:
> finalize. But as you reacted somewhat testily on this topic I postponed
> the implementation of this functionality until this feature is
> implemented (besides that, the function transformers already do add
> themselves to a wrapper class if there is one, but they just don't force
> the creation of a wrapper class).
They should. Can you give me few good reasons to not create wrappers?
> > self.curr_code_creator.associated_decl_creators.append(fwrapper)
> >
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > You had bug in this line. You did not added fwrapper to code creators tree.
> > Thus you did not defined its logical place. Thus
> > multiple_files_t.associated_decl_creators ignored it.
>
> All right. I've seen that you moved the associated_decl_creators list to
> the class registration_based_t which is a base class for calldef_t. So
> far so good. But how is this list used? What are the requirements on the
> code creators that may be put into this list?
They should belong to module_t code creator
> Just to test how it behaves, I added a code creator to the list of a
> wrapper function creator to see where it gets written. But I never
> noticed a difference, no matter if it was inside
> associated_code_creators or not. If the code creator was not hooked into
> any other part of the code creator tree, it didn't get written at all
> and if it was added to the root, it just got written into the main C++
> file.
> So how is this feature used?
This feature is still under development and it is possible I have bugs.
I jus verified that I did not break the working code. I will try to
finish the feature
in a day or two
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
