[Freeciv-Dev] Re: OO model and abstraction layer,

["Sam BC" <sambc@xxxxxxxxxxxxxxxxxxx>]

We aren't just talking about an OO document summing up the pseudo-OO
structure of the FreeCiv code... we're talking about re-writing it truly OO
in C++.

Certainly, the way you discuss a common parent class for city and unit
(called entity or something?) is not possible by abstraction in C, unless
you #include some code into both files, which is a bit of a cop out and does
no RTTI, and does not allow virtual functions (pure or otherwise). No-one
has directly denied that there are significant advantages to C++, and I
don't think anyone will.

However, we're not talking about taking over with C++! We're talking about
an OO splinter group producing a different version. Speaking of which, a
group ObjectCiv has been created on SourceForge... I will be getting the
mailing lists and project description up soon. Anyone have some odd
objection to me posting that info here?

SamBC

> -----Original Message-----
> From: freeciv-dev-bounce@xxxxxxxxxxx
> [mailto:freeciv-dev-bounce@xxxxxxxxxxx]On Behalf Of Nicolas BRUNEL
> Sent: 04 May 2000 01:16
> To: Sam BC
> Cc: Freeciv Development Mailing List; Tuomas Airaksinen
> Subject: [Freeciv-Dev] OO model and abstraction layer,
>
>
> 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
>
>
>
>
>
>