pygccxml-development

[pygccxml-development] How to do error checking?

[Matthias B. <ba...@ir...>]

Hi,

I'm still at adding function transformer support to non-virtual 
functions. When transformers are applied to a set of methods, it can 
happen that several (overloaded) methods end up with an identical 
signature. Currently, this would result in an error during compilation 
because a function is redefined.
So I'd like to check this and issue a warning in such cases. The check 
itself is no problem, but it requires sort of "global" data (namely a 
dictionary with the signatures that have been created so far) on a 
per-class basis. So there are two questions now:

1. Where should I store that data? (should I just add it to the class_t 
code creator instance?)

2. Does the Py++ design already specify where such a check should be 
done? (currently, I would probably do it in 
mem_fun_transformed_wrapper_t when the actual code gets generated)


- Matthias -

Re: [pygccxml-development] How to do error checking?

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

On 9/12/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> I'm still at adding function transformer support to non-virtual
> functions. When transformers are applied to a set of methods, it can
> happen that several (overloaded) methods end up with an identical
> signature. Currently, this would result in an error during compilation
> because a function is redefined.
>
> So I'd like to check this and issue a warning in such cases. The check
> itself is no problem, but it requires sort of "global" data (namely a
> dictionary with the signatures that have been created so far) on a
> per-class basis.
>
> So there are two questions now:
>
> 1. Where should I store that data? (should I just add it to the class_t
> code creator instance?)
>
> 2. Does the Py++ design already specify where such a check should be
> done? (currently, I would probably do it in
> mem_fun_transformed_wrapper_t when the actual code gets generated)

I suspect that you still don't understand the design.

You need function signatures for 2 cases:
    1. to register it ( def )
    2. to check uniqueness

So, why don't you add to the "function ( final ) transformation_t"
class new method:
"signature". This method will return [member|free] function type. This
will solve you both
problems:
1. You will be able to generate code, that will include function
signature( type ) in it.
    Take a look on generated code for overloaded functions.

2. In decl_wrappers.class_t you "override" _readme_impl method that
will check for
    the "problems". This method will be called from
creator_t.prepare_decls method

Answer to the first question: you don't have to store "the data".
( Performance is not an issue ).

Answer to the second question: mem_fun_transformed_wrapper_t should concern on
code generation and nothing else. So, it is a wrong place to put this
functionality to it.

Does it sound reasonable to you?

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

Re: [pygccxml-development] How to do error checking?

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
> So, why don't you add to the "function ( final ) transformation_t"
> class new method: "signature". 

I assume you mean the class function_transformer_t, right? This class 
cannot return the entire signature because it doesn't know it.
Even the substitution_manager class cannot know the signature for sure 
as it just provides string substitution services. It's up to the code 
creator to determine how the final signature will look like. (Note: I'm 
describing the current implementation here, I'm not saying that this is 
the one and only way to go, it's how it currently goes)
If you think this is not right, then we might have to introduce an 
intermediate object that is located between the substitution manager and 
the code creator (but at least so far, I wouldn't know what the 
difference between this object and the code creator would be).

> This method will return [member|free] function type. 

As a string or as a type_t object?

> 2. In decl_wrappers.class_t you "override" _readme_impl method that
> will check for
>    the "problems". This method will be called from
> creator_t.prepare_decls method

You don't happen to have a call sequence diagram of all this, have you? 
(this would probably make things clearer, because I don't understand how 
a decl_wrapper object can know things that a code creator object will be 
doing)

> Answer to the first question: you don't have to store "the data".

Well, but in contrast to the tests that are currently done by Py++ this 
test cannot be done by inspecting the current declaration alone, but it 
also needs to know information about other declarations. So where does 
this information come from?

> Answer to the second question: mem_fun_transformed_wrapper_t should 
> concern on
> code generation and nothing else. So, it is a wrong place to put this
> functionality to it.

I'll try to keep that in mind...

- Matthias -

Re: [pygccxml-development] How to do error checking?

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

On 9/12/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > So, why don't you add to the "function ( final ) transformation_t"
> > class new method: "signature".
>
> I assume you mean the class function_transformer_t, right? This class
> cannot return the entire signature because it doesn't know it.
> Even the substitution_manager class cannot know the signature for sure
> as it just provides string substitution services. It's up to the code
> creator to determine how the final signature will look like. (Note: I'm
> describing the current implementation here, I'm not saying that this is
> the one and only way to go, it's how it currently goes)
> If you think this is not right,

We talk about this. Yes I don't agree with you. I understand that you
are talking about
current implementation. Lets try to find solution within the current code.

> then we might have to introduce an
> intermediate object that is located between the substitution manager and
> the code creator (but at least so far, I wouldn't know what the
> difference between this object and the code creator would be).

I think that substitution manger should become an implementation detail of
"[final|whole|function]_transformation_t" class.

It will provide next services:
1. signature -> returns function type
2. is_static - this is because staticmethod should be called after all
registrations
3. create_declaration_code() -> retuns string that contains FT
declaration\\definition
4. call_policies
5. optional:
        * alias -> returns function transformation alias
        * documentation -> returns documentation string
        * optional: keywords and default values


> > This method will return [member|free] function type.
>
> As a string or as a type_t object?

As a free_function_type_t or member_function_type_t type.

> > 2. In decl_wrappers.class_t you "override" _readme_impl method that
> > will check for
> >    the "problems". This method will be called from
> > creator_t.prepare_decls method
>
> You don't happen to have a call sequence diagram of all this, have you?

No :-(. Ask me questions.

> (this would probably make things clearer, because I don't understand how
> a decl_wrapper object can know things that a code creator object will be
> doing)

Hmm, now I understand why you are confused. decl_wrapper classes "understands"
what code is going to be created, by they don't know the exact details.
For example: decl_wrappers understands what operators are supported, but they
don't know what code will be created to expose them.

> > Answer to the first question: you don't have to store "the data".
>
> Well, but in contrast to the tests that are currently done by Py++ this
> test cannot be done by inspecting the current declaration alone, but it
> also needs to know information about other declarations. So where does
> this information come from?

This is your design and implementation, so please tell me? By the way I don't
understand how you are going to implement it at all( in current
implementation), string
comparison?

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