Faré fahree@gmail.com writes:
Bad reasons to split:
- ease of browsing? Nope, it's harder when split.
You have to search for text in all files, lookup an index to see the order (that does matter).
- speed of compiling? Nope, for hours of maintenance, you only get a few
fractions of a second of speedup in the rare case that you only make a simple change to a file that leaves all APIs untouched. And only on a few implementations where you can somehow achieve separate compilation through ad-hoc non-portable scripts. Full build takes a fraction of a second MORE time, not less time, when you first have to concatenate all the subfiles, anyway, because in the end, the reason we put it all into asdf.lisp is because it was all necessary to bootstrap ASDF.
- ease of maintenance? Nope, additional maintenance nightmare.
- ease of distribution? Nope, it's easier to distribute one Lisp file
than a directory of files.
- ease of deployment? Nope, it has to be loaded all at once,
and there's no portable way to concatenate FASLs.
- ease of bug tracking? Nope, it's easier to md5sum or diff one file
than to try to assert and maintain coherence between tens of files.
- smaller size? Nope, you only increase the total overhead,
and don't diminish the intrinsic complexity and size.
- more sizeable chunks? Nope, my screenful of emacs buffer remains
of the same size.
I'm sure we could figure out or imagine more reasons and non-reasons. But in the end, before you do such a sweeping change, can we have a rationale?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Question: How many Intel/Microsoft executives does it take to screw in a light bulb?
Answer: None, they simply make darkness an industry standard.
Let's agree to split when it reaches half the max emacs buffer size.