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.