🚀 go-pugleaf

In article <16eu8jINNhgp@agate.berkeley.edu> konstan@cs.berkeley.edu (Joe Konstan) writes:

>I've been working on some rather thick CLOS code recently and was 
>wondering how other people handle a couple of situations:

Me too.  Although I seem to have come to the same conclusions as you,
maybe this will spark a few more comments.

>1.  Load/Compile order dependencies
>
>        Certain things need to be loaded before others can be loaded
>        or compiled.  For example, class definitions must occur before
>        the class name can be used as a method specializer.
>
>        One solution is to use some version of defsystem and to
>        carefully assure that the dependencies can be met on a
>        per-file basis (i.e., no circular dependencies between files).

This intricate solution seems tedious, hard to document, hard to
maintain.  Unfortunately, I bet this solution is the most common.

>        A second alternative (which I've been using) is to create a 
>        "header" file with all of the needed declarations and
>        definitions.  This includes "empty" defclasses (no contents, 
>        just the class name and superclass names), macro definitions,
>        and some defgenerics and proclamations.  
>        The advantage of this approach is that load/compile order,
>        after loading this header, is unimportant.  A disadvantage is
>        that each class gets defined and redefined (eliciting regular
>        warnings from some compilers such as Lucid) which I imagine is
>        not very efficient.
>

This is essentially how I decided to do it, except I use the "full"
defclass.  Why do you make them "empty" and force a redefinition?  I
group files like:

package definitions
exports and imports
defclasses and defgenerics
defmethods and defuns

with macros, special variables, and proclamations interspersed as
needed.  For instance, utility macros would go before everything with
their own set of four file groups.

This splits the complete definition of a class over several files.  I
use standard postfixes for files within a group (e.g., my-class.lisp
for methods, my-class-def.lisp for defclasses, and
my-class-export.lisp for exports/imports).  All files of one group are
loaded before files of the next group.  Within a group there is little
or no order dependency (macros and other automatic code generation can
generate special cases).

I remember having a good reason for splitting the export/imports from
the defclass/defgenerics, but I can't remember or recreate it now.

>        Any other solutions or comments?  Is there anything like a 
>        define-class-forward to avoid the redefinition problem?
>
>2.  Subclasses in new packages 
>
>        ...[handling packages]...
>        It seems that there are a few options, and I'm interested in
>        which ones other people tend to use:
>
>        a)  Forget the modularity, just use a single package
>     	   Perhaps an ugly solution, but it codes and debugs
>     	   easily.
>
>        b)  Compromise the modularity and export the slot names, etc.
>     	   Also ugly, but relatively simple.
>
>        c)  Use the :: naming withing the SPECIAL-AGENT packages
>
>        d)  Specifically import the desired symbols into the
>            SPECIAL-AGENT packages either as an import-from clause in
>            the defpackage or with an import call
>     	   This seems like the best solution I've found.  I
>     	   imagine it would also be pretty easy to design
>     	   standard :import-from clauses for packages so all
>     	   children of AGENT in other packages would use the same
>     	   clause.

I too think that the best solution is d) as long as no name conflicts
result.  Resort to c) for conflicting names.  a) and b) seem like
pretty low quality options.

>
>Joe Konstan
>konstan@cs.berkeley.edu

Again, I am interested in what others think are good approaches.

doug
--------------------------------------------------------------------
Doug Morgan, doug@ads.com, (415) 960-7300
Advanced Decision Systems (a division of Booz-Allen & Hamilton Inc.)
1500 Plymouth St., Mountain View, CA 94043-1230
--------------------------------------------------------------------