Prev: looking for the uber-utilities-library
Next: Searching some references
From: D Herring on 21 Feb 2010 01:08
On 02/20/2010 10:16 PM, Duane wrote:
> You have helped me to believe that I wasn't missing anything obvious.
> Your feedback has been helpful.

Note that simply deleting or renaming the package may not portably
have the effect you want. For example, an interpreted CL might access
the new package definition, even though the code was loaded with an
old package in effect. There is also the issue of code that uses
tools like READ and FIND-PACKAGE at runtime.

I have seen a few attempts made at improving this situation, but no
easy solutions (i.e. tools to fix the current situation).


It might be a good idea for people to start defining their packages a
bit differently. On unix system, shared libraries are generally
installed as

libxyz.so -> libxyz.so.1 # symlink
libxyz.so.1 -> libxyz.1.0.0 # symlink
libxyz.so.1.0.0 # real file

The CL equivalent would be roughly
(defpackage "xyz.1.0.0"
(:nicknames :xyz.1 :xyz)
...)

However instead of hard-coding the nicknames in defpackage, a
macro/signal mechanism would be used to point everything to the latest
version.

e.g.
(defpackage :xyz.1.0.0
...)
(in-package :xyz.1.0.0)
(register-package)

The REGISTER-PACKAGE form would check for existing package nicknames
matching the current package (here :xyz and :xyz.1). If any exist and
point to a lower version, REGISTER-PACKAGE will RENAME-PACKAGE the
lower version to remove the nickname and add it to the current
package. It might be good to leverage the CL signal mechanism to
allow the user to override this behavior.

In this way, libraries can be written using short names, but a
versioning mechanism is available to handle API changes.

Later,
Daniel
First  |  Prev  | 
Pages: 1 2
Prev: looking for the uber-utilities-library
Next: Searching some references