[cdr-discuss] Re: Packaging of CDR APIs

[Richard M Kreuter]

"Tobias C. Rittweiler" writes:
> Richard M Kreuter writes:

> > 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.

I agree up to this point.

> 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?

I don't agree that leaving packages out of interface specifications is
what leads people to write compatibility libraries: compatibility
libraries sometimes smooth out differences among implementations of
interfaces, sometimes fix or hide bugs among implementations, sometimes
target lowest-common-denominators of functionality for the purpose of
being a lower bound for portability.  For the MOP, if the only
differences among MOP implementations were the namespacing, all you'd
need in a MOP compatibility library would be a trivial script to build a
package that imported and exported the right symbols.  In fact, the
differences among the CL implementors' MOPs are not so trivial, and the
compatibility libraries must therefore do more than merely setting up
some packages.  (The same is true of Gray Streams implementations,
IIRC.)

> 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.) 

You could specify interfaces this way, but then the user can't
straightforwardly load more than one library that implements such an
API, because the two libraries will collide in the package namespace.

For the case-with-test operator that people have been discussing, some
folks have brought up the idea of having a portable implementation of
whatever spec they come up with, and maybe eventually asking CL
implementors to provide an optimized version, where possible.  If the
interface specification for case-with-test says that the operator must
be available in some package by name, then a library that purports to
conform to that interface will conflict with an implementation that
purports to conform to the same interface, since they'll both be trying
to set the symbol-function on the same symbol.  Of course this can be
worked around, e.g., a library that normally provides the operator might
not define it when loading on an implementation that already defines the
operator, but then users who'd prefer to use that library's
implementation of the operator (say, because the library extends it, or
has some flaw the user relies on) won't be able to do so on that
implementation.

--
Richard