Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > > Perhaps, but I'm for cleaner code. Having to keep deprecated stuff > around (and worse: having to write various deprecation wrappers for > them) is detrimental to code quality.
I would say the contrary is worse. Users following the advertised rules are told (exaggerated for rhetorical effect :-) "sucked in; we said there was this feature, we encouraged you to use it, now it's gone". If guile is the official extension language, used by all gnu packages (in principle) then it's a serious problem. I expect the effect in practice is, at each incompatible change, to throw off people who can't, or are not inclined to, update. For example gcc stuck to autoconf 2.13 for a long long time because subsequent changes were incompatible (even though they were cleaner in both concept and implementation). Or you end up with versionitis, like 5 versions of automake all in debian at the same time, because they each have subtle different effects (even if sensible packages are ok with any of them). > If the consensus is that removing deprecated features will not ever be > done, then there is little point in marking routines as such, and > writing wrappers to signal their use. Yes. "Don't do it" is the motto. > We could clean up GUILE by throwing away all the bookkeeping. It has to stay for applications of course. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
