Re: [Bug-gnubg] The match and game data structure

[Paul Hankin]

On 30 Jun 2006, at 13:48, Øystein Johansen wrote:

> > Anyway it could look something like:
> >
> > for (i = 1; i < getNumGames(); i++)
> > {
> >      game *g = getGame(i);
> >      pmgi = getGameInfo(g);
> >      ...
>
> Here's my (first) suggestion:
>
> GList game = match->games;
>
> for ( ; game ; game = game->next ){
>   GList move = game->moves;
>   for ( ; move ; move = move->next )
>     analyse(move);  /* or do something else */
> }

Hi, I'm new here, but have a lot of experience developing C programs
professionally. Anyway, the first solution (sorry, the attribution
has been lost) is almost always the correct approach; it's called
data abstraction and it makes things MUCH cleaner and means the
details of the datastructures don't matter to modules external to
the match/game/move. At the end there's some initial ideas about
what move.h, game.h and match.h might look like taking this approach.

What's the advantage of this for gnubg?
1. The header files are clear, clean and well-documented. As a
result the datatypes are easy to use.
2. The datatypes are insulated from the rest of the code, so it's
easy to change from linked lists to double linked lists or to
hashtables or even having matches stored in a database (not that
I think that is sensible :)
3. The python interface can be the same as the C interface. This
is a huge win as it means the interfaces get designed only once.

Obviously the choice of datastructures that you're suggesting
Øystein is still correct; it's just that they get hidden in
their appropriate module and are accessed via the functions
defined in their header file. If you would like some help
(re)designing the interfaces I'd be happy to oblige.

--
Paul Hankin

gnubg.txt
Description: Text document