From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22619 invoked by alias); 20 Nov 2003 10:58:08 -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 22612 invoked from network); 20 Nov 2003 10:58:08 -0000 Received: from unknown (HELO outbound28-2.lax.untd.com) (64.136.28.160) by sources.redhat.com with SMTP; 20 Nov 2003 10:58:08 -0000 Received: (qmail 19961 invoked from network); 20 Nov 2003 10:58:06 -0000 Received: from 66-52-241-156.sttl.dial.netzero.com (HELO vangogh) (66.52.241.156) by smtpout02.lax.untd.com with SMTP; 20 Nov 2003 10:58:06 -0000 From: "Brandon J. Van Every" To: "xconq" Subject: RE: growth agendas and OO Date: Thu, 20 Nov 2003 10:59:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20031120103708.GV387@adlp.org> X-SW-Source: 2003/txt/msg00839.txt.bz2 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.