Книга: Practical Common Lisp
Packaging Reusable Libraries
Packaging Reusable Libraries
While working on the e-mail database, you might write several functions related to storing and retrieving text that don't have anything in particular to do with e-mail. You might realize that those functions could be useful in other programs and decide to repackage them as a library. You should define a new package, but this time you'll export certain names to make them available to other packages.
(defpackage :com.gigamonkeys.text-db
(:use :common-lisp)
(:export :open-db
:save
:store))
Again, you use the COMMON-LISP
package, because you'll need access to standard functions within COM.GIGAMONKEYS.TEXT-DB
. The :export
clause specifies names that will be external in COM.GIGAMONKEYS.TEXT-DB
and thus accessible in packages that :use
it. Therefore, after you've defined this package, you can change the definition of the main application package to the following:
(defpackage :com.gigamonkeys.email-db
(:use :common-lisp :com.gigamonkeys.text-db))
Now code written in COM.GIGAMONKEYS.EMAIL-DB
can use unqualified names to refer to the exported symbols from both COMMON-LISP
and COM.GIGAMONKEYS.TEXT-DB
. All other names will continue to be interned directly in the COM.GIGAMONKEYS.EMAIL-DB
package.
- CHAPTER 4 Functions and Libraries in mikroC
- Building on Mono's Libraries
- 15.3. Debugging with Shared Libraries
- CHAPTER 21 Leveraging Java Libraries
- Appendix B Examining the .Net Class Libraries Using the Object Browser
- 7.3 But what about existing libraries?
- Packaging Mechanics
- 7.3.1 Modifying libraries to be thread-safe
- 7.3.2 Living with legacy libraries
- Creating Static Libraries
- Implementing a Boot Loader from Existing Libraries
- Driver Language and Libraries