JavaPackageConventions

This topic lays out the structure of the Java packages for CLforJava. The current topic is a proposal - subject to debate by the full development team.

Proposed Structure

Root and Top Level

Since the product is an implementation of a Lisp dialect, the root of the package structure is lisp. The next level divides the code into 3 sections:

• lisp.common that organizes the Java classes that implement the public access to CommonLisp functionality
• lisp.common.extension that organizes the Java classes that implement additional public, Java-accessible Lisp functions
• lisp.system that organizes the code that is the internal implementation.

The first 2 form the public API to CLforJava. We have to get this very nearly perfect, since you're always stuck with a published API. The third layer is our internal implementation and subject to change without notice.

Next Levels

The next levels are certainly up for debate. Here's my initial thoughts.

lisp.common should be a flat package with no further structure. This follows the CommonLisp convention that all of the standard functions, variables, and constants are in the COMMON-LISP package (not to be confused with the Java package). This also allows us to take advantage of Java's package-private access mode to provide some inherent speed improvements. For example, if lisp.common.Cons implements the lisp structure, the rest of the code in lisp.common can have field-level access to the car and cdr fields. The public access to those fields would be through car and cdr methods.

lisp.common.extension doesn't have to be a flat package. This gives us room to provide major Java extensions to lisp functions without worrying about Java package conflicts.

lisp.system implements the low-level Lisp functions that we require such as the PackageSystem. I suggest that we create a set of third-level Java packages that follow the HyperSpec structure. For example lisp.system.packages, lisp.system.conditions, lisp.system.types. We could compress the list somewhat by combining related types such as packages and symbols.

-- JerryBoetje - 11 Aug 2003