From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32108 invoked by alias); 20 Nov 2003 11:36:07 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 32092 invoked from network); 20 Nov 2003 11:36:06 -0000 Received: from unknown (HELO web40902.mail.yahoo.com) (66.218.78.199) by sources.redhat.com with SMTP; 20 Nov 2003 11:36:06 -0000 Message-ID: <20031120113605.20265.qmail@web40902.mail.yahoo.com> Received: from [217.163.5.253] by web40902.mail.yahoo.com via HTTP; Thu, 20 Nov 2003 12:36:05 CET Date: Thu, 20 Nov 2003 11:51:00 -0000 From: =?iso-8859-1?q?Jakob=20Ilves?= Subject: RE: growth agendas and OO To: "Brandon J. Van Every" , xconq In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SW-Source: 2003/txt/msg00844.txt.bz2 Hello planet Earth! --- "Brandon J. Van Every" 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) {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