[cdr-discuss] Re: Packaging of CDR APIs

[Tobias C. Rittweiler]

Richard M Kreuter writes:

> "Pierre R. Mai" writes:
> > 
> > Which brings me to another question I've been meaning to bring up
> > w.r.t. the latest CDRs:  Would it be sensible to have a defined
> > package for these kinds of smallish extensions (like e.g. the index
> > types, as well), maybe cdr-cl or ext-cl, or whatever?  Has this been
> > discussed already?
>
> I don't think this has been discussed, but I could be wrong.
>
> Although it's undesirable to require a separate package for every tiny
> API, I think that in general there are drawbacks to specifying package
> names as part of interfaces (as opposed to implementations of
> interfaces).

So if I understood you correctly, you're advocating that CDR documents
specify interfaces, and---in the same spirit as the MOP---packaging is
an implementation detail. To portably make use of such an interface,
it's necessary to rely on a portability-library like SWANK-MOP or
CLOSER-MOP (which you may have to do /anyway/ due to buggy/incomplete
implementations from vendors.) Does this summarize your point fairly?


For the contrary opinion that a CDR should specify a package, notice
that you can leave the question of having one package per CDR, or a
single package for possibly several CDRs open by specifying that

  "Symbols FOO, BAR, QUUX are exported from a package named CDR-N."

This makes it possible for implementations to collect symbols of several
CDRs in one package as long as this package has nicknames CDR-X, CDR-N,
CDR-Y (as long as symbols don't collide.) 

Programs can rely on (:import-from "CDR-N" "FOO" "BAR" "QUUX") to work
portably.

  -T.