> You forgot the other important point, modularity reduces speed of > development, sometimes catastroptically, you only need to look at GNU > Hurd for an example of that.
i see the exact opposite of behaviour at work. Project initiated in a modular way, or migrated to a modular approach are easier to manage for the following reasons 1) You don't need to have knowledge of how the whole code works to be able to work on parts of it 2) You can isolate changes in only a part of the code > > It strikes me that crossfire is (still) not yet mature enough to have > a fixed interface to all the modules that would be used, only a couple > of months ago all the python scripts were broken by a plugin change, > and I know I for one wouldn't want to attempt to fix the weather > 'module' the next time the interface to it was broken. > Architecture must be handled from the very beginning and currently there is no architecture design on crossfire project. A way to structure things here is suggested. This may not be the best approach, but it's far better then what we currently have. And nobody in the last year did propose anything to fix architecture problems in crossfire. And in modularized projects, the interfaces between modules are not always clear, they are not fixed and would probably never been. Some code migrate from one module to another after experience show it is needed nearer to the core, or on the opposite, it get further from the core because it is not as multipurpose as we may have thought in the begin. Some modules sometimes get gathered as a unique module. Some other gets splitted in sub modules. That's the lifecycle of a project. It works, and well. Yes sometimes there are clash, sometimes a very big change in a module is a pain in the ass for all people using the modules. But considering the gain, in development speed, in code learning curve and bugs hunting, it is clearly worth it. You argue a change in 'core' could interfer with 'weather' and you don't want to fix weather if it gets broken by that change in core? Well i claim, with current organisation of code, a change *anywhere* in code (not only what we could define as core) can break the weather. (Or potentially break anything else). That is something a modularized approach tends to prevent as much as possible. And am not speaking of compilation here. Compilation problems are easy to solve. You could argue, currently, you can't make a change in core that would make weather uncompilable, which with a plugin system could be possible. But, this is not a difficult fix, the most difficult bugs to fix are those which let the code compilable but with subtle invalid logic. And the last one happends a lot in crossfire. regards _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
