From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: Re-addition of deprecated stuff to 1.7. Date: 17 May 2003 19:22:23 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87iss97ak0.fsf@zagadka.ping.de> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1053192727 27101 80.91.224.249 (17 May 2003 17:32:07 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 17 May 2003 17:32:07 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat May 17 19:32:06 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19H5XR-00072y-00 for ; Sat, 17 May 2003 19:32:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19H5Xh-00048G-07 for guile-devel@m.gmane.org; Sat, 17 May 2003 13:32:21 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19H5XY-00045s-00 for guile-devel@gnu.org; Sat, 17 May 2003 13:32:12 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19H5XW-00045h-00 for guile-devel@gnu.org; Sat, 17 May 2003 13:32:11 -0400 Original-Received: from gnuftp.gnu.org ([199.232.41.6]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19H5Wv-0003lN-00 for guile-devel@gnu.org; Sat, 17 May 2003 13:31:33 -0400 Original-Received: from mail.dokom.net ([195.253.8.218]) by gnuftp.gnu.org with esmtp (Exim 4.10.13) id 19H5Oc-0004uc-00 for guile-devel@gnu.org; Sat, 17 May 2003 13:22:58 -0400 Original-Received: from dialin.speedway42.dip31.dokom.de ([195.138.42.31] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19H5QB-0006PE-00 for guile-devel@gnu.org; Sat, 17 May 2003 19:24:35 +0200 Original-Received: (qmail 11311 invoked by uid 1000); 17 May 2003 17:22:23 -0000 Original-To: Neil Jerram In-Reply-To: Original-Lines: 82 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:2388 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2388 Neil Jerram writes: > >>>>> "Marius" == Marius Vollmer writes: > > Marius> Hi, I have started to re-add most of the things that were > Marius> deprecated in 1.6 and removed in 1.7. I hope everyone > Marius> agrees that this is OK. > > Yes, but can it be done in a way that the back compatible bits are > kept separate from the core? Yes, mostly. When too much need to change just to support a re-added deprecated thing, I'm not re-adding it. For example, vcells are not coming back. > A while ago you mentioned something like _GNU_SOURCE, which seems > exactly right to me. > > For example, an application would just say > > #define _GUILE_SOURCE 1.6 > #include > > And a 1.7.x/1.8.x libguile.h would have something at the end like > > #if _GUILE_SOURCE = 1.6 > #include > #endif Hmm, I don't think I would want to include version numbers explicitely in this mechanism. I would say that when some code wants to be compiled against the Guile 1.6 API, it should be compiled against Guile 1.6. But with a version specific switch, we can have conflicting APIs. But for that, I'd say, we should have one switch per conflicting feature. And that switch could be deprecated over time... To illustrate, consider the change from a two-arg version of scm_eval to the three-arg one. When making the decision to make that change (instead of just adding a new function), we can offer a switch that activates the three-arg version: /* old code, using two-arg eval */ #include ------------------- /* new code, using three-arg eval */ #define GUILE_ENABLE_THREE_ARG_EVAL #include Later, we can deprecate the 'enable' variant and prefer a 'disable' one: /* old code, using two-arg eval */ #define GUILE_DISABLE_THREE_ARG_EVAL #include ------------------- /* new code, using three-arg eval */ #include And still later, we can just remove GUILE_DISABLE_THREE_ARG_EVAL and let the old code fail. > Marius> The idea is that we should backwards compatability for a > Marius> longer time when it is easy enough to do. I am adding the > Marius> things in as clean a way as possible, so that they do not > Marius> get in the way of the mainline code. > > It's possible that I may have described what you are already doing, > then :-) Maybe... I try to only modify the files deprecated.c, deprecated.h and deprecated.scm. The rest of the code remains mostly untouched. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel