[cdr-discuss] Re: Packaging of CDR APIs

[Marco Antoniotti]

Q.E.D.

The worms are squirming around. :)

Cheers
--
Marco




On Mar 18, 2008, at 19:44 , Richard M Kreuter wrote:

> "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
> _______________________________________________
> cdr-discuss mailing list
> cdr-discuss at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/cdr-discuss

--
Marco Antoniotti