pygccxml-development

[pygccxml-development] FT - open issues

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

Hi. I think Py++ accumulated enough changes, so we can start on
preparing it to be released. Before we do this, I prefer to see few
issues fixed in FT:

1. Better formatting of generated code.
2. Name uniqueness\resolution. For example:
    for next C++ code

    namespace ft{
    struct xxx_t{
        static void get_value( int& x ){ x = 21; }
     private:
        ~xxx_t(){}
     };

   Py++ generates next code

   static boost::python::object _py_get_value(  ) {
       int x;
       xxx_t::get_value(x);
       return boost::python::object(x);
   }

   Obviously if I will introduce similar class with other name, Py++
will not generate
   unique name for get_value.

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.

4. Base class for all transformations should be introduced.

5. Class that represents "final" transformation should be introduced.

6. Generated code should be different. I mean we should introduce more
convenience
    functions in code repository.

I can help with 4,5,6 items.

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

Re: [pygccxml-development] FT - open issues

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

Roman Yakovenko wrote:
> 2. Name uniqueness\resolution. For example:
>     for next C++ code
> 
>     namespace ft{
>     struct xxx_t{
>         static void get_value( int& x ){ x = 21; }
>      private:
>         ~xxx_t(){}
>      };
> 
>    Py++ generates next code
> 
>    static boost::python::object _py_get_value(  ) {
>        int x;
>        xxx_t::get_value(x);
>        return boost::python::object(x);
>    }
> 
>    Obviously if I will introduce similar class with other name, Py++
> will not generate unique name for get_value.

You're right. (On the other hand, this other class might reside in its 
own source file anyway which reduces chances for a name clash)
I'll see what I can do. I guess it shouldn't be a problem to incorporate 
the class name into the function name.

> 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.

> 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).

> 6. Generated code should be different. I mean we should introduce more
> convenience functions in code repository.

Right, I haven't had the time yet to incorporate all the stuff from that 
other thread. But speaking of which, I did try to find that 
boost::python::len function you were mentioning but couldn't find it 
anywhere.

- Matthias -

Re: [pygccxml-development] FT - open issues

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

On 10/4/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > 2. Name uniqueness\resolution. For example:
> >     for next C++ code
> >
> >     namespace ft{
> >     struct xxx_t{
> >         static void get_value( int& x ){ x = 21; }
> >      private:
> >         ~xxx_t(){}
> >      };
> >
> >    Py++ generates next code
> >
> >    static boost::python::object _py_get_value(  ) {
> >        int x;
> >        xxx_t::get_value(x);
> >        return boost::python::object(x);
> >    }
> >
> >    Obviously if I will introduce similar class with other name, Py++
> > will not generate unique name for get_value.
>
> You're right. (On the other hand, this other class might reside in its
> own source file anyway which reduces chances for a name clash)
> I'll see what I can do. I guess it shouldn't be a problem to incorporate
> the class name into the function name.
>
> > 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 ). Matthias please consider to change to
0 based.

> > 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?

> > 6. Generated code should be different. I mean we should introduce more
> > convenience functions in code repository.
>
> Right, I haven't had the time yet to incorporate all the stuff from that
> other thread. But speaking of which, I did try to find that
> boost::python::len function you were mentioning but couldn't find it
> anywhere.
>
> - Matthias -
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> pygccxml-development mailing list
> pyg...@li...
> https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>


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

Re: [pygccxml-development] FT - open issues

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

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)

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.

>> > 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.

- Matthias -

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/

Re: [pygccxml-development] FT - open issues

[Allen B. <al...@vr...>]

Does this mean that the current svn version should be stable enough 
right now to start using/testing.  I must admit that with all the 
changes you and Matthias have been introducing I have not updated my 
checked out copies for several weeks.  I have been waiting for things to 
stabilize so I didn't break my development system. :)

I am more then happy to help test things though if the time has come.

-Allen


Roman Yakovenko wrote:
> Hi. I think Py++ accumulated enough changes, so we can start on
> preparing it to be released. Before we do this, I prefer to see few
> issues fixed in FT:
> 
> 1. Better formatting of generated code.
> 2. Name uniqueness\resolution. For example:
>     for next C++ code
> 
>     namespace ft{
>     struct xxx_t{
>         static void get_value( int& x ){ x = 21; }
>      private:
>         ~xxx_t(){}
>      };
> 
>    Py++ generates next code
> 
>    static boost::python::object _py_get_value(  ) {
>        int x;
>        xxx_t::get_value(x);
>        return boost::python::object(x);
>    }
> 
>    Obviously if I will introduce similar class with other name, Py++
> will not generate
>    unique name for get_value.
> 
> 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.
> 
> 4. Base class for all transformations should be introduced.
> 
> 5. Class that represents "final" transformation should be introduced.
> 
> 6. Generated code should be different. I mean we should introduce more
> convenience
>     functions in code repository.
> 
> I can help with 4,5,6 items.
> 
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> pygccxml-development mailing list
> pyg...@li...
> https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>