Juan Jose Garcia-Ripoll juanjose.garciaripoll@googlemail.com writes:
On Thu, Sep 23, 2010 at 4:27 AM, Pascal J. Bourguignon pjb@informatimago.com wrote:
But when you have a smart editor such as emacs, with at least a good search function, or even a find-tag feature, it doesn't really matter where your functions are stored.I use emacs, and I am not thinking about searching functions, which has been also repeated to me privately as a reason (!) to have everything in one file, but rather in organizing the code and giving it a navigational structure. I find it useful at least for myself to split things into directories according to their role, group functions that belong together at least in my mind and work only on a small set of files at a time.
That said, there are times when this is impossible, as it is the problem with ECL, which has humongous files with hundreds of functions per-file. In this case there are two issues at stake, one is that C only makes optimal function calls to functions in the same file (maybe that changes with new link time optimizers) and the other one is to avoid exporting symbols.
In C, these problems can be solved with #include.
----(compile-unit.c)-------- #include <source1.c> #include <source2.c> #include <source3.c> // <- not .h, but .c ----------------------------
Actually, file management should be left up to the system and the programmer should not care about the storage of their functions. Like in Smalltalk for example. So instead of dealing with a linear sequence of functions, you can rather work on a tree or graph of functions, and navigate from one to the other directly.Sorry, but I always found Smalltalk's way of working confusing. You just throw everything in a huge, deep, dark bag and everything is at your hand's reach, but that does not mean one gets a really organized project out of it. For me programs are more than just a collection of functions, but that is my personal taste.
They provide a browser to organize things by category of classes and category of methods in addition to the class hiearachy.
That said, I too like to have things gathered up in a somewhat organized way, so that I may browse and revise the code in a meaningful way. But there are probably better ways to do it. In particular when you consider multiple dispatch in CLOS, you could have several ways to sort out the methods, depending on what you're doing.My point is that even if there are many ways to do so, one of them imprints the actual view of the library or program organization. Using code layout as information for newcomers is fine and that is what I am trying to do -- being kind of a newcomer to lots of ASDF parts.
Juanjo