|
From: Matthias B. <ba...@ir...> - 2006-09-10 08:48:46
|
Hi, I'm currently trying to support the function transformers on non-virtual functions (i.e. mem_fun_t). It works fine when the corresponding class also has virtual functions so that a wrapper class gets created anyway and there's a place where I can stick the wrapper for the non-virtual function. But if Py++ does not create a wrapper then there's no "hook" where I could add the wrapper function. As far as I can tell there doesn't seem to be a way to add a node to the code creator tree that will only appear in the source file for one specific class. Would it be possible that during the creation of the code creator tree Py++ also creates special nodes such as, for example, translation_unit_t which marks the root of everything that goes into a particular file? Each wrapper class node would then be a children of the corresponding translation unit node. Instead of filtering out class nodes the multiple file writer would then have to filter out the translation unit nodes and stick everything beneath such a node into one file. That way, the user would have the option to put arbitrary nodes into one specific file. Or is there already a simple workaround to get the above behavior? - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-09-10 09:00:49
|
On 9/10/06, Matthias Baas <ba...@ir...> wrote: > > Hi, > > I'm currently trying to support the function transformers on non-virtual > functions (i.e. mem_fun_t). It works fine when the corresponding class > also has virtual functions so that a wrapper class gets created anyway > and there's a place where I can stick the wrapper for the non-virtual > function. But if Py++ does not create a wrapper then there's no "hook" > where I could add the wrapper function. As far as I can tell there > doesn't seem to be a way to add a node to the code creator tree that > will only appear in the source file for one specific class. Read documentation please :-) http://language-binding.net/pyplusplus/documentation/inserting_code.html#insert-code-to-class Would it be possible that during the creation of the code creator tree > Py++ also creates special nodes such as, for example, translation_unit_t > which marks the root of everything that goes into a particular file? > Each wrapper class node would then be a children of the corresponding > translation unit node. > Instead of filtering out class nodes the multiple file writer would then > have to filter out the translation unit nodes and stick everything > beneath such a node into one file. That way, the user would have the > option to put arbitrary nodes into one specific file. This will not work. Take a few minutes to think about and if you don't understand why, I will provide the answer. Or is there already a simple workaround to get the above behavior? Yes, it is described in documentation. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Matthias B. <ba...@ir...> - 2006-09-10 21:12:04
|
Roman Yakovenko wrote: > Read documentation please :-) > http://language-binding.net/pyplusplus/documentation/inserting_code.html#insert-code-to-class Ah, oops, sorry, I missed that one... class_t.add_declaration_code() can be considered a decoration function, right? So until what stage is it valid to call this function? Is it ok to call it *after* the actual decoration stage? I think the time when I'll be calling it will be while the code creator tree is just being built. - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-09-11 05:35:55
|
On 9/11/06, Matthias Baas <ba...@ir...> wrote: > Roman Yakovenko wrote: > > Read documentation please :-) > > http://language-binding.net/pyplusplus/documentation/inserting_code.html#insert-code-to-class > > Ah, oops, sorry, I missed that one... > > class_t.add_declaration_code() can be considered a decoration function, > right? So until what stage is it valid to call this function? Is it ok > to call it *after* the actual decoration stage? I think the time when > I'll be calling it will be while the code creator tree is just being built. You can only call this function before code creators tree construction. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Matthias B. <ba...@ir...> - 2006-09-11 07:57:04
|
Roman Yakovenko wrote: >> I'm currently trying to support the function transformers on non-virtual >> functions (i.e. mem_fun_t). It works fine when the corresponding class >> also has virtual functions so that a wrapper class gets created anyway >> and there's a place where I can stick the wrapper for the non-virtual >> function. But if Py++ does not create a wrapper then there's no "hook" >> where I could add the wrapper function. > > In this case Py++ should create wrapper. You mean a wrapper class, not a wrapper function, right? > The code that finds out > whether wrapper is > needed or not should be moved from the factory ( > module_creator.creator_t ) to the decl_wrapper.class_t. This is a > re-factoring that should be done. I agree that this refactoring is desirable and should be done, but it won't provide a solution to my current problem (only a workaround). I only want to make the wrapper function (i.e. a free function, not a member function) available in the corresponding source file so that it can be referenced in the registration function for the class. I don't want to force Py++ to create a wrapper class when it's not absolutely necessary. So this either requires something like class_t.add_declaration_code() that is also available at the time the code creator tree is built or a way to specify the file that a particular code creator object belongs to (personally, I think the latter would be more intuitive and fit the framework better as we're already dealing with code that happens after the decoration stage). - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-09-11 08:32:36
|
On 9/11/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> >> I'm currently trying to support the function transformers on non-virtual
> >> functions (i.e. mem_fun_t). It works fine when the corresponding class
> >> also has virtual functions so that a wrapper class gets created anyway
> >> and there's a place where I can stick the wrapper for the non-virtual
> >> function. But if Py++ does not create a wrapper then there's no "hook"
> >> where I could add the wrapper function.
> >
> > In this case Py++ should create wrapper.
>
> You mean a wrapper class, not a wrapper function, right?
Yes.
> > The code that finds out
> > whether wrapper is
> > needed or not should be moved from the factory (
> > module_creator.creator_t ) to the decl_wrapper.class_t. This is a
> > re-factoring that should be done.
>
> I agree that this refactoring is desirable and should be done, but it
> won't provide a solution to my current problem (only a workaround).
> I only want to make the wrapper function (i.e. a free function, not a
> member function) available in the corresponding source file so that it
> can be referenced in the registration function for the class. I don't
> want to force Py++ to create a wrapper class when it's not absolutely
> necessary.
I prefer to create class wrapper:
1. This will be the consistent behaviour. There are a lot of places,
where Py++ creates
class wrapper, even if it is not absolutely necessary
2. This behaviour very easy to explain.
3. There is at least one important use-case when this behaviour makes
it easier to
work with Py++ - integration with already existen code.
> So this either requires something like class_t.add_declaration_code()
> that is also available at the time the code creator tree is built
This is not the way design pattern "factory" works. So the answer is not.
> or a
> way to specify the file that a particular code creator object belongs to
> (personally, I think the latter would be more intuitive and fit the
> framework better as we're already dealing with code that happens after
> the decoration stage).
Not a best solution. I think you missed the trivial solution. Please
read this document
http://language-binding.net/pyplusplus/documentation/architecture.html
and then search for associated_decl_creators string within the package.
Come back if you need more tips :-).
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
|
From: Matthias B. <ba...@ir...> - 2006-09-11 09:26:41
|
Roman Yakovenko wrote: >> way to specify the file that a particular code creator object belongs to >> (personally, I think the latter would be more intuitive and fit the >> framework better as we're already dealing with code that happens after >> the decoration stage). > > Not a best solution. I think you missed the trivial solution. Please > read this document > http://language-binding.net/pyplusplus/documentation/architecture.html > and then search for associated_decl_creators string within the package. So the associated_decl_creators property seems to be what I meant above (a way to specify that a particular code creator belongs to the same file than a particular class). :) But there's another problem now. How can the member function creator obtain a reference to its parent class creator (so that it can access the associated_decl_creators property) or rather: *when* can it do that? During construction of the member function creator it is not yet added to the code creator tree, so its "parent" property isn't initialized yet. And when it is added later on it doesn't get notified about this and I haven't seen another place where it could do initializations. The only methods I've seen are called after create() has been called and at that time we're already at the stage when the files are written, so that's too late for adding something to associated_decl_creators. - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-09-11 09:40:46
|
On 9/11/06, Matthias Baas <ba...@ir...> wrote: > So the associated_decl_creators property seems to be what I meant above > (a way to specify that a particular code creator belongs to the same > file than a particular class). :) Yes > But there's another problem now. How can the member function creator > obtain a reference to its parent class creator (so that it can access > the associated_decl_creators property) using parent property :-) > or rather: *when* can it do that? Every function transformation consist from 2 parts: function wrapper definition and registration, right. Take a closer look on creator_t class. When you create relevant code creators you have to inject them to the right position. In your case you will have to add wrapper to the tree and to the associated_decl_creators. But still I prefer you to add it to the class wrapper. Please do it this way. > During construction of the member function creator it is not yet added > to the code creator tree, so its "parent" property isn't initialized > yet. And when it is added later on it doesn't get notified about this > and I haven't seen another place where it could do initializations parent is initialized when you call adopt_creator method. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Matthias B. <ba...@ir...> - 2006-09-11 13:15:47
|
Roman Yakovenko wrote: >> or rather: *when* can it do that? > > Every function transformation consist from 2 parts: function wrapper > definition > and registration, right. Take a closer look on creator_t class. When you > create > relevant code creators you have to inject them to the right position. > In your case you will > have to add wrapper to the tree and to the associated_decl_creators. Hm, so in addition to implementing the actual mem_fun_transformed_t and mem_fun_transformed_wrapper_t classes I have to modify code at the following locations: - code_creators/__init__.py: Modify guess_mem_fun_creator_classes() so that it returns the transformed versions when appropriate. - module_creator/creator.py: Modify creator_t.visit_member_function() so that it adds the appropriate code creator object to the list of associated creators for the current class. When the option is turned on that Py++ should always create a wrapper class I also have to modify the following places: - module_creator/creator.py: Modify either creator_t.visit_class() or creator_t._is_wrapper_needed() (or both?) so that a wrapper class is created when there's a member function that has function transformers assigned to it. I think this is rather complex and what I don't like about it is that code that belongs together is scattered over several files (even from different sub-packages). I would really prefer if I could keep all my code local to the place where the member function code creators are implemented. This would simplify maintenance. For example, the visit_member_function() method could invoke an initialization method on the code creator that allows that method to do the work that would otherwise be located in visit_member_function(). Then it would be nice if it was possible to register functions that are invoked by guess_mem_fun_creator_classes() and that can check if they know how to handle a particular declaration, etc. So all in all, it would be great if everything would be a bit more extensible so that a modification like the one that I'm currently trying to do could even be done externally without having to modify internal Py++ code. Or in my case where it actually is an internal modification, everything could be kept local to one file (or at least one sub-package). - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-09-11 13:34:43
|
On 9/11/06, Matthias Baas <ba...@ir...> wrote:
> Hm, so in addition to implementing the actual mem_fun_transformed_t and
> mem_fun_transformed_wrapper_t classes I have to modify code at the
> following locations:
>
> - code_creators/__init__.py: Modify guess_mem_fun_creator_classes() so
> that it returns the transformed versions when appropriate.
This function should me moved to create module_creator package and yes,
you will have to modify it
> - module_creator/creator.py: Modify creator_t.visit_member_function() so
> that it adds the appropriate code creator object to the list of
> associated creators for the current class.
Yes
> When the option is turned on that Py++ should always create a wrapper
> class I also have to modify the following places:
"Turned on" means: there is at least one FT
> - module_creator/creator.py: Modify either creator_t.visit_class() or
> creator_t._is_wrapper_needed() (or both?) so that a wrapper class is
> created when there's a member function that has function transformers
> assigned to it.
I think _is_wrapper_needed will be enough. Although I should move this function
to decl_wrappers package with explanation, why wrapper is needed.
> I think this is rather complex and what I don't like about it is that
> code that belongs together is scattered over several files (even from
> different sub-packages).
I don't think that this code "belongs" together. Think about this:
creator_t class solves "location" problem - where the generated code
should be logically
written, while code creators answer the "what" question - what code
should be created.
> I would really prefer if I could keep all my
> code local to the place where the member function code creators are
> implemented. This would simplify maintenance.
Not for me, because the responsibilities will be less clear more over
it will be difficult
to diagnose the problems.
> For example, the visit_member_function() method could invoke an
> initialization method on the code creator that allows that method to do
> the work that would otherwise be located in visit_member_function().
1. Every code creator has __init__ function
2. The only job any code creator should do is generate code. It is not
allowed to modify
the tree, more over it is not allowed to do something else.
> Then it would be nice if it was possible to register functions that are
> invoked by guess_mem_fun_creator_classes() and that can check if they
> know how to handle a particular declaration, etc.
> So all in all, it would be great if everything would be a bit more
> extensible so that a modification like the one that I'm currently trying
> to do could even be done externally without having to modify internal
> Py++ code.
If you want to extend creator_t you will have to derive from it or to
modify its
implementation. This is the right way to do it. Please read one more
time the document,
that describes the architecture. Py++ consists from few simple and
dummy concepts. This
is the real power of it. This is your first time you add feature that
works with code creators.
I am sure that in few days you will appreciate the design.
> Or in my case where it actually is an internal modification,
> everything could be kept local to one file (or at least one sub-package).
After moving guess_... to module_creator everything will be in a
single sub-package.
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
|
From: Matthias B. <ba...@ir...> - 2006-09-11 14:56:46
|
Roman Yakovenko wrote:
>> - module_creator/creator.py: Modify creator_t.visit_member_function() so
>> that it adds the appropriate code creator object to the list of
>> associated creators for the current class.
>
> Yes
Currently, it means I have to insert code like this into
visit_member_function():
if maker_cls==code_creators.mem_fun_transformed_t:
....
This doesn't feel the "right" way to me, but if it's the recommended way
(and as long as it works) I won't complain anymore... ;)
>> When the option is turned on that Py++ should always create a wrapper
>> class I also have to modify the following places:
>
> "Turned on" means: there is at least one FT
That's not what I meant. I meant an option that controls whether the
presence of function transformers (on non-virtual functions) result in
the creation of a wrapper class or not. I think that's basically the
finalize functionality (I started a new thread about this).
>> I think this is rather complex and what I don't like about it is that
>> code that belongs together is scattered over several files (even from
>> different sub-packages).
>
> I don't think that this code "belongs" together. Think about this:
> creator_t class solves "location" problem - where the generated code
> should be logically
> written, while code creators answer the "what" question - what code
> should be created.
Just to make sure this is not a misunderstanding: I didn't mean that
everything has to be put into one single class. There may be any number
of separate classes or functions, each with its own responsibility. But
it would be great if I could keep those classes together in one file
because I still think that conceptually, this stuff belongs together
(even though one part solves the location problem and the other part the
"what" question, those two parts can only exist together and both is
required to support transformed member functions).
>> Then it would be nice if it was possible to register functions that are
>> invoked by guess_mem_fun_creator_classes() and that can check if they
>> know how to handle a particular declaration, etc.
>> So all in all, it would be great if everything would be a bit more
>> extensible so that a modification like the one that I'm currently trying
>> to do could even be done externally without having to modify internal
>> Py++ code.
>
> If you want to extend creator_t you will have to derive from it or to
> modify its
> implementation. This is the right way to do it.
Deriving from creator_t has a few problems:
- The module builder class instantiates the creator object and it does
that from the builtin creator_t class, not from any derived class.
- If I wanted to modify the behavior of, say, visit_member_function() I
would have to replace the entire method. This basically means I would
have to copy the existing code, paste it into my derived class and do my
modifications (after I have understood what's going on in that method
anyway). This is not what I understand by "encapsulation".
- This might just be me, but I would have considered methods like the
visit_*() methods to be internal methods that are an implementation
detail of the creator class. So if I have to override those internal
methods I run the risk that my own script will be broken when used with
future versions of Py++ where some internal stuff has been changed.
- Matthias -
|
