cl:find-package
¶Even without the modifications to cl:find-package
, authors need
not avoid using relative package names, but the ability to reuse
relative package names is restricted. Consider for example a module
foo which is composed of the my.foo.bar
and
my.foo.baz
packages. In the code for each of the these packages
there are relative package references, ..bar
and ..baz
.
Implementations that have the new cl:find-package
would have
:relative-package-names
on their *features*
list (this is the case of CMUCL releases starting from 18d). Then,
in the foo module, there would be definitions of the
my.foo.bar
and my.foo.baz
packages like so:
(defpackage :my.foo.bar #-relative-package-names (:nicknames #:..bar) ...) (defpackage :my.foo.baz #-relative-package-names (:nicknames #:..baz) ...)
Then, in a #-relative-package-names
implementation, the symbol
my.foo.bar:blam
would be visible from my.foo.baz
as
..bar:blam
, just as it would from a
#+relative-package-names
implementation.
So, even without the implementation of the augmented
cl:find-package
, one can still write Common Lisp code that will
work in both types of implementations, but ..bar
and
..baz
are now used, so you cannot also have
otherpack.foo.bar
and otherpack.foo.baz
and use
..bar
and ..baz
as relative names. (The point of
hierarchical packages, of course, is to allow reusing relative package
names.)