Re: Make GDB build with python 2.4 again.

[Pedro Alves <pedro@codesourcery.com>]

On Monday 20 October 2008 00:40:40, Tom Tromey wrote:
> >>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

> >> Note that in current gdb/python sources, additional changes
> >> are required for python2.4 if Py_ssize_t isn't fixed as above ...
> 
> Pedro> That looks strange, since ssize_t isn't usually the same size
> Pedro> of int.
> 
> My belief is that Py_ssize_t is a 2.5 introduction, and places using
> Py_ssize_t used to use int.  That is why the patch was written the way
> it was.
> 

Ok then.

> >> > 2008-10-19  Pedro Alves  <pedro@codesourcery.com>
> >> >
> >> >        * python/python-value.c (value_object_methods)
> >> >        (value_object_as_number, value_object_as_mapping): Move to bottom
> >> >        of file.
> 
> Paul> Why?
> 
> Pedro> To avoid all the forward references, so that we don't have to change
> Pedro> two places whenever an interface changes, or things like these happen.
> 

> This is an issue -- a minor one -- for three reasons.
> 

> First, in general, it is better to commit code rearrangements and bug
> fixes as separate patches.
> 

I tend to follow that trend, as you can see by my latest commits.
In this case, I wasn't that it was annoying me visually.  It was
either move, or add two ifdefs.  :-/  Exacly the reason we should
avoid forward declarations.

> Finally, there is nothing to say that the preferred gdb style is to
> avoid forward declarations.  So, we picked a style we liked -- not
> unintentionally, at least on my part, but because I like having the
> "class definition" at the top, followed by method implementations,
> followed by the initialization code.  All the python code follows this
> outline.

If you look at most other cases where we use a structure holding
function pointers, like e.g., target_ops instances, languages, debug
info readers, you'll see that we define the code, and register the
function pointers at the end of the file.  For new code, we should
try avoiding them, it's just unneeded extra work to adjust them
when interfaces change.

> 
> I'll look at moving this change to the python branch tomorrow (unless
> someone gets there first).  If you want all the forward declarations
> removed from the python code, please let me know, and I'll implement
> that on the branch as well.

I'd prefer that similar new code avoids forward declarations, yes.

However, I'm also fine with reverting my last change, and
applying Paul's if that's less work for you.  Heck, that's why we
use a revision control system.

-- 
Pedro Alves