Re: [pygccxml-development] [pygccxml-commit] SF.net SVN: pygccxml: [534] pygccxml_dev/pygccxml/declarations/calldef.py

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

Roman Yakovenko wrote:
> On 9/11/06, Matthias Baas <ba...@ir...> wrote:
>> Oops, I wasn't aware that I broke that rule. Uhm, but what did I do that
>> actually broke it? I haven't used anything from pyplusplus (or other
>> external code).
> 
> Yes I know, dummy_type_t was defined in pygccxml for convenience reason.
> 
>> The only class that I've used is dummy_type_t which is defined within
>> pygccxml. And the behavior of the argument class was not changed, it was
>> just an addition so that the type argument can now also be a string. Any
>> existing code should continue to work as before.
> 
> No. I have to fix some bug. But basically consider next case
> 
> argument_t( 'x', type='const std::string&', ... )

I'm surprised to see that this was already allowed! It wasn't documented 
what type the 'type' argument was actually supposed to be, but from 
looking at the sources it seemed to be required that it was derived from 
type_t. And when I did some tests where I did pass strings I got 
exceptions somewhere inside Py++ where it tried to access the 
decl_string property, so I was pretty sure that strings had been invalid 
as arguments. And that's why I thought I wouldn't break anything when I 
do allow them.

But obviously I did break something. I don't understand why and I don't 
see how this was obvious from looking at the sources, but anyway. So my 
apologies for any inconveniences! I'll roll back my changes right away.

Sorry again.

- Matthias -