Complete.Org: Mailing Lists: Archives: freeciv-dev: May 2000:
[Freeciv-Dev] OO model and abstraction layer,
Home

[Freeciv-Dev] OO model and abstraction layer,

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Sam BC <sambc@xxxxxxxxxxxxxxxxxxx>
Cc: Freeciv Development Mailing List <freeciv-dev@xxxxxxxxxxx>, Tuomas Airaksinen <tuma@xxxxxxxxxxxx>
Subject: [Freeciv-Dev] OO model and abstraction layer,
From: Nicolas BRUNEL <brunel@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 4 May 2000 00:16:11 +0000 (GMT)

Sum up : A OO document may help people contribute to Freeciv. If
completed, this document will contain a description of an abstraction
layer for Freeciv.

Hello,

    some people are interested in developping a c++ version of Freeciv. As
has said Renier Post, it would be very interesting to describe the
Freeciv classes and how they are linked together. In Freeciv, a 'c class'
corresponds to a file.( Well, I hope so.) As exemple, the 'c class' unit
corresponds to unit.c for the code and unit.h for the interface. People
doing such a document will spot functions in the wrong file or confusing
files with too many differents things in it or hidden classes. It's not
always obvious where to put a new function. The same document will also
describe what is expected in each file. The server/common part won't be
too difficult as classes are easy to find. The ai part will be
tougher. The ai code is efficient. But, it takes time to understand
it. Functions are long too. The huge work will be to describe the client
part. It will be as difficult as doing an abstraction layer for the
clients. Here, OO can really help. Many problems were caused by unproper
destruction or construction. Pointers were not set to zero after a dialog
was closed. Or, a dialog was designed to be open only once. But, the
client allows to open it more than once. The challenge is here to describe
how the different dialogs are related one to another and to control their 
construction and destruction.

    Something, I'd like to see is flying cities. Structs unit and city
share many fields. Often, there is 'if (pcity)' then 'if (punit)'. Or, 
'x = punit->x; y = punit->y;' and later 'x = pcity->x; y = punit->y;'.
Code can be generalized here (mother class of unit and city ?). 

   Abstraction layer was on the roadmap on a long time ago. It's a
worthwhile project but not an easy one !

Bye,

Nicolas






[Prev in Thread] Current Thread [Next in Thread]