Just to chime in in the middle: There is no known solution to the so-called 
"DLL hell" problem. Libraries interact badly because of their interactions, not 
because one or the other is "bad." Even with the best of intentions, a library 
author cannot predict what changes will break existing clients and what changes 
won't, because that author doesn't know about all possible interactions. When 
APIs change, telling clients that they are now incompatible may be a lie, 
because they may not depend on the specific change. (For example, is the 
addition of a keyword argument an incompatible change or not? It may, or it may 
not be...)

You are basically trying to solve the halting problem for a program where you 
don't know significant parts of the program. ;)

There is a field of research about component-oriented programming where this 
was a hot topic for quite some time, and nothing ever came out of it. The only 
practical working solution was that of Microsoft COM, where you need to change 
a GUID when APIs change, and since it's a black box model, that covers a lot of 
ground. Common Lisp libraries are definitely not black box, so even this 
solution will probably not work that well. (Changing the name of the library or 
the system definition, as Vsevolod suggests, would be similar.)

If you want to give control to developers, you could provide a way that 
depends-on specifications are list designators, with some form of declarative 
way of precisely specifying which versions are compatible and which aren't. 
(Then you could describe situations like, compatible with everything up to and 
including 0.9.x, and everything above 1.0.0, but excluding 1.0.0 - a situation 
that actually occurred when Closer to MOP was incompatible with SBCL 1.0.0 for 
a brief moment in history... ;)

Pascal

Sent from my iPad

> On 20 Nov 2013, at 14:34, Vsevolod Dyomkin <vselo...@gmail.com> wrote:
> 
> I think, you're both right. :)
> 
> I have a similar experience of migrating a large Java application through 
> changes of versions of Jetty from 6th to 9th, and it was much less painful 
> when the namespaces were changed (between v. 6 and 7 if I'm not mistaken) for 
> the points mentioned by Anton. So I think, it indeed makes sense to create, 
> say, hunchentoot2 if there's going to be again a serious incompatible API 
> change, like the transfer from 0.X to 1.X. (But a transfer from 0.X to 1.X is 
> an exception here, because it is assumed that until v.1 the software is not 
> stable).
> 
> At the same time, if you make a small "local" API change, it often doesn't 
> justify creating a new package & system, because there will be more total 
> inconvenience for those who aren't affected (the majority) to migrate to the 
> new version than for those who are affected to change their code.
> 
> So it all just boils down to common senses, some level of discipline and the 
> amount of change some system really needs to go through intrinsically. My 
> guess is that for the vast majority of libraries such dramatic version 
> transitions may happen once in several years, and it totally makes sense for 
> me to do a new namespace/system for that.
> 
> Best regards,
> 
> ---
> Vsevolod Dyomkin
> +38-096-111-41-56
> skype, twitter: vseloved
> 
> 
>> On Wed, Nov 20, 2013 at 2:50 PM, Anton Vodonosov <avodono...@yandex.ru> 
>> wrote:
>> 19.11.2013, 23:41, "Robert P. Goldman" <rpgold...@sift.info>:
>> > it's too radical
>> It's not radical, actually my proposal is very similar to yours
>> 
>> > It's like having a purely functional programming language
>> Yes, I see this as an FP analogy too and expect that avoiding
>> mutations and destructive changes will simplify life
>> for developers.
>> 
>> > with no garbage-collection!
>> Why without garbage-collection? We are not leaking any resources.
>> 
>> > We'd be left with heaps of unmaintained and unmaintainable
>> > versions of basic-lib floating around in the worse case.
>> 
>> The amount of library versions does not change in the approach
>> I propose. But versions with different APIs are have different names.
>> 
>> And we deal only with versions we use, and can forget about any
>> other versions.
>> 
>> > Also, the two different libraries won't live happily in the same lisp
>> > image, unless they change package
>> 
>> Wait, I do propose to change package
>> 
>> > at every release
>> 
>> at every API incompatible change (in other words, for every new API).
>> 
>> > This approach seems like it will be such a monumental pain for the
>> > library maintainers,
>> 
>> What pain do you mean? It's a zero cost solution. It requires no
>> additional efforts from library maintainer, and even no special
>> support from ASDF and other tools.
>> 
>> > and anyone who wishes to upgrade his/her client program
>> > from basic-lib to basic-lib2
>> 
>> The client job remains the same: if he wants to migrate to
>> the new API he rewrites parts of his code using new functions.
>> Nothing above that.
>> 
>> Moreover, as client can have access to both APIs simultaneously,
>> he can sometimes migrate partially: leave his old tested code
>> as is (using basic-lib), but in the places where he needs
>> new functionality he calls basic-lib2.
>> So, client can benefit from new features without investing
>> efforts into rewriting and retesting code.
>> 
>> > I'd argue that having two versions of the same library *in the same
>> > image* is too demanding a target.
>> 
>> It's not a target. The target is to not break clients.
>> It's rather a tool to achieve this target, or a pleasant side-product
>> of a cheap decision to name different things differently.
>> 
>> Please think about this approach a little more.
>> IMHO this approach is convenient and I would recommend
>> it as the first thing to consider to anyone who is going
>> to change API of a public library.
>> 
>> Am I missing anything?
>> 
>> Best regards,
>> - Anton
> 

Reply via email to