This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
RE: growth agendas and OO
- From: "Brandon J. Van Every" <vanevery at indiegamedesign dot com>
- To: "xconq" <xconq7 at sources dot redhat dot com>
- Date: Thu, 20 Nov 2003 03:08:46 -0800
- Subject: RE: growth agendas and OO
Bruno Boettcher wrote:
>
> wasn't there allready someone slowly pushing into that direction? the
> first step was to get xconq compiled with g++, AFAIK we are at this
> step..
Apparently so.
> so maybe we need a design phase here which reorganizes the sources?
We do not, I repeat, *not* want to do this top-down all at one go.
Rather, we need a migration path. We want an incremental, hodgepodge,
piece here, piece there approach. That's what's appropriate for the
volunteer labor actually available to Xconq. A hodgepodge OO approach
may sound bad, but it's better than Xconq's current C code. The C code
is actually not totally far off from OO, it's just too flat.
Improvement is the point, not creating tons of work that has no fungible
value to anyone. Also, incremental testing is the point. You cannot
move a big system like Xconq over to something else all at once.
Once Xconq has done "hodgepodge OO" for awhile, it may become feasible
to turn it into "highly structured OO." Also, more ambitious
improvements become possible. For instance, it is really not feasible
or sane for most people to attempt new GUIs with the code being the way
it is. Some OO paradigm simplifications are necessary first.
In short, there really is nothing to argue about as to what the
structure of the OO should be. Rather, pick an OO language tool, and
start OOing some minor things, with the hope of that leading to major
things. I'm picking Python. Others could pick C++ if they like that,
or some other language if they're terribly motivated. Then it becomes a
matter of who actually codes, who actually uses the language tools.
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
Taking risk where others will not.