This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: growth agendas and OO


Hello planet Earth!

 --- "Brandon J. Van Every" <vanevery@indiegamedesign.com> skrev: > 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.

Absolutely!

(Hodgepodge being offered?  That sounds delicious, maybe I should consider returning to earth!)

This is a very good way of developing, introducing (and needing to kill) just one bug (if any) for
every step.  Sure, one can do large chunks and exterminate all those bugs all at once but they can
become awfully persistent if they gang up against the poor developer.  They are far nicer to
eliminate one at a time (trust me, I've used both approaches ;-).

Given that Xconq is rather large, a good test suite would be most useful.  That way the developer
can reasonably quickly check if the last step in the development caused an bug or not.

Multiple migration paths could be nice, that way one developer can turn one piece into OO on
his/her box while othes deals with other pieces.  Then both check in their pieces into the
development CVS.  Yes, coordination will be needed among parallell OO migraters so their changes
don't happen to clash (for example, check out the entire current CVS source and do a run against
test suite in order to identify any incompatible OO migration pieces checked in).

Having one developer alone doing the OO work probably is a bad idea, IMHO.  That person will be a
bottleneck for the project and the risk is big that the person get's fed up with the task or even
worse, what must not happens do indeed happen: that the developer no longer find it fun to develop
Xconq.

> 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.

Um... Java?  Using the Apache Batik SVG for the graphics?  With XGDL for defining games and with
Javascript for snippets in the game definition code.  What a fantasy!

Seriously, Java have advantages but I don't see any way of incrementally migrating Xconq to Java
from C.  Too bad, but such a monolithic migration would likely be suicide.  C++ could be a choice,
or at least an intermediate step.  Once the OO is there, be it "hodgepodge" or "highly structured"
flavor, it would be a less painful suicide to do a migration, all at once, to say Java or some
other language.

For an excersice in utter programming perversion (which is fun at times ;-), we can go for Perl
and Perl-tk.

> Cheers,                     www.indiegamedesign.com
> Brandon Van Every           Seattle, WA
> 
> Taking risk where others will not.

/IllvilJa  (still in orbit ;-)

Having fun where others will not ;-)  (Sorry could not resist that one).



=====
(Jakob Ilves) <illvilja@yahoo.com>
{http://www.geocities.com/illvilja}

Höstrusk och grå moln - köp en resa till solen på Yahoo! Resor på adressen http://se.docs.yahoo.com/travel/index.html


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]