Greets, On Wed 12 Nov 2008 11:11, [EMAIL PROTECTED] (Ludovic Courtès) writes:
> Andy Wingo <[EMAIL PROTECTED]> writes: > >> I think we went wrong in the 1.4->1.6 and 1.6->1.8 transitions, by >> leaving /source files/ to bitrot. We should have provided >> guile-1.6-compat.[ch] and guile-1.8-compat.[ch] files for users to >> include in their source trees, wrapping e.g. the gh_* API, or SCM_INUM. >> That way their code stays usable, ours stays maintainable, and whenever >> they decide to port to the new API, they already know how -- it's in >> their source tree. > > Hmm, we have `gh.c' and `deprecated.c', which are kind enough to (i) > provide compatibility wrappers, and (ii) tell users how to upgrade to > the new API. What do you dislike about it? Oh, I think they're great :) But for example, Clinton was complaining earlier this week in IRC (#guile on freenode, for those that don't know) about the removal of the gh API in 1.9. I think Bruno did too some months back. Etc. It's totally reasonable to remove dead code like that from Guile itself, but at every bump we should push those shims *out to the user*, so they can have the compatibility shims in their source code. > Or maybe you're referring to things like `guile-compatibility.h' in > G-Wrap? Basically, it allows G-Wrap to use the latest API and have it > work with the older versions of Guile. That is another nice option, for those in group (2) who actively follow Guile development. Cheers, Andy -- http://wingolog.org/
