🚀 go-pugleaf

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

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).

	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.

	Any other solutions or comments?  Is there anything like a 
	define-class-forward to avoid the redefinition problem?

2.  Subclasses in new packages 

	Some of what I'm doing best modularizes the code by having
	subclasses in a separate package from the base class.  For
	this discussion, assume that the base class is AGENT and the
	subclass SPECIAL-AGENT.  The AGENT class exports the symbols
	AGENT, MAKE-AGENT, and some of the accessors that would be 
	used by clients of agent.  Slot names, in general, are not 
	exported as the user of an AGENT has no reason to know or care
	about the internal structure.

	Now SPECIAL-AGENT comes along.  New slots are easily defined,
	but it is rather difficult to change the definition of the 
	existing slots (e.g., to add a new initform) since the slot
	name is not exported (result is either agent::slot-name or 
	accidently defining a new slot called
	special-agent::slot-name.  

	Assume that there are several SPECIAL-AGENT type classes, each
	in different packages (with other code unrelated to AGENT)
	but related to that SPECIAL-AGENT.

	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.

	e)  Some other solution?

I can't imagine that I'm the first person to look for a systematic way
of handling these situations.  I'm particularly interested in seeing
if there is enough of a consensus that one solution really would
improve readability/changeability among CLOS programmers.

Joe Konstan
konstan@cs.berkeley.edu