> Seems like a sort of odd decision since most recent conversations have > seemed to have decided that more content and less code work is what is > really needed to be done, but this seems to be a big code project...
Yes, it has the potential to be ambitious. > And just given the size and changes of the project, I'd like to see more > detailed information - this isn't a minor change being made here. I plan on having design documents before coding, so hopefully we'll have time to think things over. So I can't give much details now, as I don't know them all :) Is that a satisfactory anwser? :) > I also wonder that given such a rewrite if maybe a more drastic approach > is needed. IMO, one reason for the messy/bad code is to maintain > compatibility - new things are added, but don't want to break old > maps/archetypes/whatever. I think some things could be simplified a great > deal (or made more efficient) if it was considered OK to break some of that > compatibility - this may mean lots of maps need updating, but if you're > going to do a major rewrite, it may be an overall plus just to give up on > some of that compatility for clean code. Indeed, but then let's do the whole thing and convert *ALL* things. One of the reasons for the mess is that people (me included, quite certainly) don't do the conversion globally, and only change a few maps/archs, thus we need to keep old compatibility code. > I do remember a long time ago someone else looked at doing crossfire in > C++, and his decision was basically to do it from scratch - better to write > something that meets the functional spec than to try and figure out what > all that code does, etc. But that is clearly a larger project. A plus is > that with a complete re-write, one could at least architect it for certain > things. But then you start asking questions on what is crossfire really, > etc. As Yann mentioned in another mail, rewriting from the ground up with copy / paste can be a solution. > I think it sort of depends on the expected development model. But I'd > generally say do it as a branch. > > If individual changes were limited in scope to a few files and were > basically complete at each commit, then maybe working directly in trunk > would be OK. But changing languages would seem that that is less likely > case. . > > The flip side is also that if not many changes are being made in the > trunk, it should generally be fairly easy to keep up to sync (there aren't > changes be made that requires syncing up, etc) I think it'll be on a branch, yes. > I do have some concerns like Kevin's, in that the rewrite could take a > long time (I have no idea on your expected schedule on this, so maybe not). > I'd actually be more concerned that the trunk gets left in some hybrid > state - some stuff rewritten, some stuff not, and unclear if having 30% of > it rewritten in C++/Qt and rest be old C is better than 100% in old C. Doesn't matter. Current C code builds in C++ easily, so no "is that C or C++?" philosophical question :) (and that's not a theoritical reply, I did test a few months ago - code didn't change enough to warrant another test) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !]
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
