That is what the hurd project thought at the begining, the reality is diffrent.
--- tchize <[EMAIL PROTECTED]> wrote: > > > 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 > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
