Re: [pygccxml-development] FT - open issues

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

On 10/8/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> >> > 3. transformers index argument from 1 and not from zero. I think we
> >> > need to discuss
> >> >     this one more time. I don't agree with this interface. This is
> >> > tooooo confusing.
> >>
> >> Here's a piece of code from the Boost.Python tutorial:
> >>
> >> def("f", f,
> >>      return_internal_reference<1,
> >>          with_custodian_and_ward<1, 2> >());
> >>
> >> The numbers 1 and 2 refer to the first and second argument. So I would
> >> find it confusing if Py++ would do it otherwise.
> >>
> >> Besides that, I've reserved the index 0 to represent the return value.
> >
> > Because 0 represents self ( this ).
>
> Well, you say yourself that 0 does not represent the first value from
> the argument list. So what's your point? (by the way, the above code
> refers to a free function so there is no self/this)

Even global functions in Python has "self" argument.

> If the function transformers would be 0-based it could happen that one
> and the same argument has to be referred to by two different values,
> depending on the context. If the user applies a function transformer he
> would have to use the index 0 for the first argument whereas if he also
> applies a call policy he would have to use the index 1 for the very same
> argument. This is inconsistent.

It should not be consistent in this case.

> >> > 4. Base class for all transformations should be introduced.
> >>
> >> There is one already: function_transformer_t
> >> You may certainly derive from that class if you wish, it's just that you
> >> don't have to (because this class just defines/documents the interface
> >> and doesn't contain any actual code).
> >
> > Where is the code that decides what method should be called and what not?
>
> I'm not sure what "decision" you are referring to, but the methods are
> called in the substitution_manager_t class.

I will post my decision about this in another thread.

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