[asdf-devel] New ASDF maintainer sought

Pascal J. Bourguignon pjb at informatimago.com
Thu Sep 23 13:25:32 UTC 2010


Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> writes:

> On Thu, Sep 23, 2010 at 4:27 AM, Pascal J. Bourguignon <pjb at 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


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/





More information about the asdf-devel mailing list