pygccxml-development

[pygccxml-development] Terminology - help needed

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

Hi. I am working on final functionality
( Similar to Pyste one :
http://www.boost.org/libs/python/pyste/doc/renaming_and_excluding.html )

I have small/big problem. I can not create good names for functions/propert=
ies.

Please give a name to the next functionality:

does declaration have wrapper?
should declaration have wrapper?
do not create wrapper.

Also for example in order to expose protected member function pyplusplus
creates wrapper, in this case user can just set ignore  flag to true and it=
 will
not be exposed. Do you think I should call helper function as "wrapper" too=
?

Pure virtual function must have wrappers, so I want to indicate to user tha=
t
he can not remove/finalize the function and wrapper.

Constructors also have wrappers, but the only reason for their
existence is that I should create them correctly if I want to wrap
some another function. Should I call those constructor in wrapper
class  "wrappers" too?

I hope you understand my confusion. If you have some idea, any idea
you welcome to share.

If we will not find good terminology, I think I will not implement
this functionality.
In general it is very easy to implement it, but I can not find good names :=
-(

Thanks for help.

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

Re: [pygccxml-development] Terminology - help needed

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

Roman Yakovenko wrote:
> Please give a name to the next functionality:

How about:

> does declaration have wrapper?

bool = has_wrapper()

> should declaration have wrapper?

create_wrapper(bool=True)
enable_wrapper(bool=True)

or do you mean:

bool = requires_wrapper()

> do not create wrapper.

create_wrapper(False)
enable_wrapper(False)
disable_wrapper(bool=True)

> Also for example in order to expose protected member function pyplusplus
> creates wrapper, in this case user can just set ignore  flag to true and it will
> not be exposed. Do you think I should call helper function as "wrapper" too?

At least, this sounds reasonable to me.

> Constructors also have wrappers, but the only reason for their
> existence is that I should create them correctly if I want to wrap
> some another function. Should I call those constructor in wrapper
> class  "wrappers" too?

As they are the constructors of a wrapper class I think it makes sense 
to call them "wrappers", too.

- Matthias -

Re: [pygccxml-development] Terminology - help needed

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

On 3/20/06, Matthias Baas <ba...@ir...> wrote:

Thanks a lot. :-)

property has_wrapper
    property, that indicates whether pyplusplus should create wrapper or no=
t.
    For example virtual function has_wrapper, but user can set it to false,=
 to
    disable generation of it

def enable_wrapper
def disable_wrapper
    sets has_wrapper to true/false

def requires_wrapper
    returns true if the only way to expose declaration is to create
some wrapper for it.
    For example pure virtual function, protected function or function
that takes as argument
    non const reference to fundamental type.

relevant functionality of decl_wrappers.class_t is implemented in
terms of child declarations.

Is it clear description of what is going on?

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

Re: [pygccxml-development] Terminology - help needed

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

Roman Yakovenko wrote:
> property has_wrapper
>     property, that indicates whether pyplusplus should create wrapper or not.
>     For example virtual function has_wrapper, but user can set it to false, to
>     disable generation of it
> 
> def enable_wrapper
> def disable_wrapper
>     sets has_wrapper to true/false
> 
> def requires_wrapper
>     returns true if the only way to expose declaration is to create
> some wrapper for it.
>     For example pure virtual function, protected function or function
> that takes as argument
>     non const reference to fundamental type.
> 
> relevant functionality of decl_wrappers.class_t is implemented in
> terms of child declarations.
> 
> Is it clear description of what is going on?

So far it looks clear to me (but I didn't need wrappers for the Maya SDK 
yet (there are only a few classes that are actually meant to be derived 
from by the user), so it may well be that I overlook some issues...).

- Matthias -