In the approach I advocate, this works without problem.

If the two versions of date library are incompatible, say datelib and datelib2, 
 then we in principle can not pass a value produced by xmllib:parse-date to 
dblib:save-object(date2-obj) because these objects are of different type. 
Application author knows he can't do this.

If the two versions of the date library are compatible - the same API, then 
module loader should only load one version.

Or you mean evolution of libraries. When dblib initially depended on datelib, 
and then changed the dependency to datelib2 ? 

In this case the _public_ API of dblib changes - yesterday dblib:save-object 
was accepting datelib:date object, and today it accepts datelib2:date. So new 
version of dblib should become dblib2. As long as application author uses old 
dblib, everything is compatible. When the application author wants to use 
dblib2 he is aware that is different API and he sees that the function 
dblib2:save-object can't accept the date value he has.

22.05.2016, 14:53, "Hans Hübner" <hans.hueb...@gmail.com>:
> 2016-05-22 13:33 GMT+02:00 Anton Vodonosov <avodono...@yandex.ru>:
>> 19.05.2016, 11:00, "Hans Hübner" <hans.hueb...@gmail.com>:
>>> The real issue though is data types defined by versioned libraries.  
>>> Suppose that an instance of a data type defined in library A version 1 is 
>>> passed, through higher levels of the software, to version 2 of that same 
>>> library.  How would one ever expect that to work?
>>
>> Can that happen without us on the higher level knowingly passing object 
>> created by one API, to another, incompatible API, which doesn't accept such 
>> objects?
>>
>> I was thinking about that too, but now it appears to me that if incompatible 
>> changes in API are marked as such (e.g. by giving the API new name), we 
>> always know that the second API is incompatible and can not accept this 
>> object.
>>
>> Do you have examples? It would be interesting to explore this problem 
>> further.
>
> Let's assume that we're using, say, an XML library that can parse dates into 
> instances of a date library, and a database library that accepts instances of 
> date objects of said library for insertion into a database.  If the XML 
> library and the database library depended on different versions of the date 
> library and it'd be allowed to have two versions of the date library in one 
> running lisp image, we'd end up passing date instances created by the XML 
> library to the database library.
>
> -Hans

Reply via email to