Am Sonntag, 26. April 2009 schrieb Holger Rapp:
> I prefered one level hierarchies here, because doxygen doesn't show
> down to more than one level (see screenshot: economy, editor, ui and
> io are
> marked red (that means "not completly shown") because they have
I have not run my own tests, but that sounds like there are too many
dependencies altogether, no matter the dir depth. The doxygen-1.5.4 doc says:
The reason why a graph is sometimes truncated is to prevent images from
becoming too large. For the graphs generated with dot doxygen tries to limit
the width of the resulting image to 1024 pixels.
> Back to my design problem: there are only a 89 source files remaining
> in the
> src/ directory. Many of them are concerned around Worlds, Tribes,
> Maps, Workers,
> Wares, Bobs, Immovables (while Tribe and World are something special
> because they are not also Map_Objects, compared to the rest). some
> other contain
> 'logic' classes like Game or Player and even some others contain helper
> functionality that is used in many places (log, wlexception, upcast.h).
> The question is now: where to put the remaining functionality?
> I think about a utils module for the last class of files.
Please don't, there's way too many "utils", "shared" and "common" code
around ;-) Just leave them where they are, shouldn't clobber things too much.
> The first two classes
> make me headaches. Maybe 'models' or 'simulation' for the first class
> and 'logic' for the second?
"simulation" sounds fine to me. I'm not sure that models and logic can (or
should) be separated in that context - model-view-controller is not the right
paradigm to use _inside_ the simulation backend, IMNSHO.
Basically, anything that holds data for "inside" the simulated world belongs
together because it's strongly connected. Separate dirs for enumerated code
(e.g. triggers, events) still make sense though.
Game and Player look like they might be controller objects, but don't they
also hold state that is needed for the simulation?
> What about profile and journal? They both are io, but at a very high
Give Section it's own file and put Section and Profile in their own
subdir "profile/". That stuff really is a library of it's own. In theory, if
not in immediate practice, it could be replaced by any of a dozen similar
ones from sourceforge.
Journal ... hmmm, I don't really know. It's not io/. It's not map_io/. Nor
game_io/. But it could fit together with log.*.
Since most of these categories _will_ be remixed as refactoring continues, why
not leave Journal where it is until a fitting category pops up? That's how I
organize my document archives: it all goes into one directory. If that
directory a) has more than 10 files and b) at least three of those are
somewhat similar those get their own, new dir. Repeat for all subdirectories,
reverse algorithm when (re)moving files.
For the very distant future, I could imagine our toplevel src/ organized
roughly according to MVC, with generic helpers directly in src/.
While you're at it: can't we get rid of most (all) "widelands" inside
filenames? I remember a relevant discussion about "widelands_fileread.h"
et.al. but can't find it quickly in my archive.
> I need opinions, people! ;)
You may scold me on (lack of) informedness or intelligence, but don't try to
claim that I'm not an opinionated SOB ;-)))
Mit freundlichen Grüßen,
PGP key id: A34C32F9