public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: "Jakob Ilves" <illvilja@yahoo.com>
To: "Brandon J. Van Every" <vanevery@indiegamedesign.com>,
	xconq <xconq7@sources.redhat.com>
Subject: RE: growth agendas and OO
Date: Thu, 20 Nov 2003 11:51:00 -0000	[thread overview]
Message-ID: <20031120113605.20265.qmail@web40902.mail.yahoo.com> (raw)
In-Reply-To: <OOEALCJCKEBJBIJHCNJDGEBKGMAB.vanevery@indiegamedesign.com>

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

  reply	other threads:[~2003-11-20 11:36 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-20  2:15 Xconq UI thoughts Stan Shebs
2003-11-20  2:26 ` Brandon J. Van Every
2003-11-20  2:57   ` Eric McDonald
2003-11-20  9:45     ` growth agendas and OO Brandon J. Van Every
2003-11-20 10:49       ` Bruno Boettcher
2003-11-20 10:59         ` Brandon J. Van Every
2003-11-20 11:51           ` Jakob Ilves [this message]
2003-11-20 12:05             ` Brandon J. Van Every
2003-11-20 17:57             ` Jim Kingdon
2003-11-20 17:24       ` Eric McDonald
2003-11-20 17:51         ` Eric McDonald
2003-11-21  1:59         ` altruistic VS 2003 Solution files Brandon J. Van Every
2003-11-21  4:17           ` Eric McDonald
2003-11-21  9:02             ` So let's get right to the point Brandon J. Van Every
2003-11-21 23:14               ` Lincoln Peters
2003-11-22  0:06                 ` Why Eric doesn't like my personal style Brandon J. Van Every
2003-11-23 11:13                   ` Mark A. Flacy
2003-11-23 14:22                     ` Brandon J. Van Every
2003-11-22  0:07                 ` So let's get right to the point Brandon J. Van Every
2003-11-21  2:01         ` growth agendas and OO Brandon J. Van Every
2003-11-20 10:31   ` Xconq UI thoughts Andreas Bringedal
2003-11-20 10:37     ` keys and menus Brandon J. Van Every
2003-11-20 10:58     ` Xconq UI thoughts Bruno Boettcher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031120113605.20265.qmail@web40902.mail.yahoo.com \
    --to=illvilja@yahoo.com \
    --cc=vanevery@indiegamedesign.com \
    --cc=xconq7@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).