On Sun, 2016-05-22 at 14:33 +0300, Anton Vodonosov wrote: > > 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.
I gave a few in a previous message here: It's easy to come up with such a case, where a library: *) switches from CL epoch timestamps(1900-based) to Unix epoch(1970) *) switches from Unix namestrings to URIs *) switches from relative CL pathnames with implicit base to absolute pathnames In each of these cases, the single versions pass their own internal (unit) tests, but they do not integrate. If libraries change the semantics of slots whose types are standard CL types, you can't even detect this without extensive integration tests. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
signature.asc
Description: This is a digitally signed message part
