pygccxml-development

[pygccxml-development] Member variables and their access type?

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

Hi,

I just noticed a slight problem with Py++. I tried to ignore private 
member variables but the class variable_t doesn't have a property 
"access_type". It seems that property is only available on classes 
derived from member_calldef_t.
So how can I check the access type of a member variable?

- Matthias -

Re: [pygccxml-development] Member variables and their access type?

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

On 10/4/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> I just noticed a slight problem with Py++. I tried to ignore private
> member variables

Py++ should ignore them by default, so I don't understand what you are
trying to do.

> but the class variable_t doesn't have a property
> "access_type". It seems that property is only available on classes
> derived from member_calldef_t.

Right, because I don't have global_variable_t and member_variable_t classes

> So how can I check the access type of a member variable?

mem_var.parent.find_out_member_access_type( mem_var )

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

Re: [pygccxml-development] Member variables and their access type?

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

Roman Yakovenko wrote:
>> I just noticed a slight problem with Py++. I tried to ignore private
>> member variables
> 
> Py++ should ignore them by default, so I don't understand what you are
> trying to do.

Well, don't worry, I guess this is just an "artifact" of using 
pypp_api... ;)
(I was just trying to get rid of some warnings)

>> but the class variable_t doesn't have a property
>> "access_type". It seems that property is only available on classes
>> derived from member_calldef_t.
> 
> Right, because I don't have global_variable_t and member_variable_t classes
> 
>> So how can I check the access type of a member variable?
> 
> mem_var.parent.find_out_member_access_type( mem_var )

Is this going to change in the future (so that there's a property 
access_type)? I think it's not intuitive that member variables have to 
be treated differently than member functions (after all, they are both 
members and the access type is a property of a member).

- Matthias -

Re: [pygccxml-development] Member variables and their access type?

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

On 10/4/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> >> I just noticed a slight problem with Py++. I tried to ignore private
> >> member variables
> >
> > Py++ should ignore them by default, so I don't understand what you are
> > trying to do.
>
> Well, don't worry, I guess this is just an "artifact" of using
> pypp_api... ;)
> (I was just trying to get rid of some warnings)
>
> >> but the class variable_t doesn't have a property
> >> "access_type". It seems that property is only available on classes
> >> derived from member_calldef_t.
> >
> > Right, because I don't have global_variable_t and member_variable_t classes
> >
> >> So how can I check the access type of a member variable?
> >
> > mem_var.parent.find_out_member_access_type( mem_var )
>
> Is this going to change in the future (so that there's a property
> access_type)? I think it's not intuitive that member variables have to
> be treated differently than member functions (after all, they are both
> members and the access type is a property of a member).

Done


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

Re: [pygccxml-development] Member variables and their access type?

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

Roman Yakovenko wrote:
>> >> So how can I check the access type of a member variable?
>> >
>> > mem_var.parent.find_out_member_access_type( mem_var )
>>
>> Is this going to change in the future (so that there's a property
>> access_type)? I think it's not intuitive that member variables have to
>> be treated differently than member functions (after all, they are both
>> members and the access type is a property of a member).
> 
> Done

Thanks! (this reduced the number of warnings from 511 to 389! :)

After updating I noticed the modification from r616 that the 
_set_arguments() method was commented out which broke the function 
transformer unit test.
What's the reason why arguments should not be set? _get_arguments() 
still returns the internal list, so the class isn't really protected 
from being modified. I'm using this as a workaround now, but obviously 
I'm not supposed to change the list...?

- Matthias -

Re: [pygccxml-development] Member variables and their access type?

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

On 10/4/06, Matthias Baas <ba...@ir...> wrote:
> After updating I noticed the modification from r616 that the
> _set_arguments() method was commented out which broke the function
> transformer unit test.
> What's the reason why arguments should not be set? _get_arguments()
> still returns the internal list, so the class isn't really protected
> from being modified. I'm using this as a workaround now, but obviously
> I'm not supposed to change the list...?

No, I had a bug, that has been discovered on huge project while using
properties.
It was very difficult to find it, so I commented the _set_arguments, I
thought it will help to find
the bug.

I committed the fix.

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