"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