Re: [pygccxml-development] [FT] small issue

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

On 9/24/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > Hi Matthias. Next code is cut-and-paste from creator_t.visit_member_function
> >
> > required_headers = getattr(fwrapper, "get_required_headers", lambda : [])()
> >
> > This code is problematic for next reasons:
> >
> > 1. When we talked about [FT], we thought that user will be able to add
> > custom
> >     function transformation, without understanding of code creators, right?
> >     I think, that putting "get_required_headers" on code creator is a
> > little bit problematic.
>
> (This point didn't contain any reason why the above code is problematic,
> you just say that you think it is problematic...?)

Because when user will try to add new transformation, he will need to
understand
code creators, this is not what we want.

> > 2. There is small design violation: creator_t should not talk to code
> > creators.
> >     creator_t is a factory. As such it should ask for required headers from
> >     function transformation.
>
> I was asking about that in an earlier mail:
>
> Roman Yakovenko wrote:
> >> The responsibility of a code creator object is to create a piece of C++
> >> source code that will be written into one or more output files, right?
> >> Now my actual question probably boils down to the following question:
> >> Whose responsibility is it to make sure that the code that was generated
> >> by a particular code creator object can also be compiled without errors?
> >
> > File writer + code creator. File writer answer the question: where to
> > put the
> > code, while code creator "what code to put". creator_t defines
> > "logical" place of the code creator, by placing it in the right place
> > within the tree. File writers insure that the "logical"
> > place of code creator is preserved.
>
> I interpret this as it is the code creator's responsibility to make sure
> that the code it generates can be compiled.

> This means that if the code
> creator generates code that requires a particular header file it must
> make sure that this header file gets included.

This is a mistake! You are assigning too much responicibilites to code creators.

Code creator in only responcible to generate valid code, the one that
could be compiled
if you put it in a right "environment".

> And because there's no
> way for a code creator to do that directly,

This is by design.

> I did it indirectly by
> providing a method that returns the required header files (which then
> have to be added by whoever is in the position to do so, I decided for
> the visit_member_function method).

This is a mistake. Factory design pattern does not work this way.

> Your suggestion to have a transformation group object that returns a
> list of header files would be less flexible than the above. The
> transformers only add code to a function but they do not know the entire
> function and as such they cannot know about the requirements of code
> that was not added by themselves.

Yes, but they will report only their parts and "transformation group
object" will
remove a duplicated items.

> Have a look at the current code, the code creator for transformed
> virtual functions requests the gil guard header file because it may
> create code that uses this header. This code is not handled by a
> function transformer, so a transformer group couldn't know about that.

This is because you decided that "thread safe" is not function transformation
but something else. You did not defined what it is. From my point of view
"thread safe" is do function transformation. This is a special case for Py++
and it should deal with it.

> So how does the current design deal with the problem that a code creator
> might generate code that requires a particular header file?

Very very simple - all this information creator_t takes from
decl_wrappers classes.

I will try to explain the architecture one more time. We are talking
about complex
code generator. Every class or package share some logic with others,
but they don't share
the details. Every package defines it's own details:

decl_wrappers - does not have details at all. This is because this
package is "one big
    interface"

code creators - the details are "how piece of code will look like"

For example:

decl_wrappers.class_t knows that when user expose some class it could set
HeldType, so it has "held_type" property. But this class does not know where
the actual held type will be generated.

 Another example: array member variable.
creator_t knows that the way to export array is to use
array_1_registrator_t creator.
It also knows that in order to use, it have to "include"
__array_1.pypp.hpp header.
But the creator_t has 0 ( zero ) knowledge how the generated code will
look like.

I hope this will help you better understand the design.

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