From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Obsoleting more progressively Date: Wed, 03 Nov 2010 01:56:10 +0900 Message-ID: <87iq0fwtp1.fsf@uwakimon.sk.tsukuba.ac.jp> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1288716891 7900 80.91.229.12 (2 Nov 2010 16:54:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 2 Nov 2010 16:54:51 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 02 17:54:46 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PDK89-0004Id-HN for ged-emacs-devel@m.gmane.org; Tue, 02 Nov 2010 17:54:41 +0100 Original-Received: from localhost ([127.0.0.1]:52847 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PDK88-0004vw-7Y for ged-emacs-devel@m.gmane.org; Tue, 02 Nov 2010 12:54:40 -0400 Original-Received: from [140.186.70.92] (port=59378 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PDK7y-0004th-GD for emacs-devel@gnu.org; Tue, 02 Nov 2010 12:54:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PDK7w-00056S-ST for emacs-devel@gnu.org; Tue, 02 Nov 2010 12:54:30 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp ([130.158.254.161]:48469) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PDK7w-00055P-IE for emacs-devel@gnu.org; Tue, 02 Nov 2010 12:54:28 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp (imss12.cc.tsukuba.ac.jp [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id B14172AF543; Wed, 3 Nov 2010 01:54:25 +0900 (JST) Original-Received: from mgmt1.sk.tsukuba.ac.jp (unknown [130.158.97.223]) by imss12.cc.tsukuba.ac.jp (Postfix) with ESMTP id A1C222AF542; Wed, 3 Nov 2010 01:54:25 +0900 (JST) Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 9CE503FA0530; Wed, 3 Nov 2010 01:54:25 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 47BF61A3EDD; Wed, 3 Nov 2010 01:56:10 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:132281 Archived-At: Stefan Monnier writes: > I can think of 2 ways to do implement that second level of obsolescence: > - Add warnings at runtime when obsolete stuff is used. > for functions, commands and macros, make-obsolete that's reasonably > easy to do; for variables it's more difficult. It's not impossible, though. Move them into C and given them a magic "forwarding" value that triggers a warning and then returns or sets the real value. (It would also be possible to do this at the LISP level with appropriate LISP primitives, I guess. That way the forwarding value can't leak out.) I would imagine that runtime warnings would severely piss off users (hi, Eli! what was that you were saying over on the bazaar list?), enough so that actively maintained packages would quickly upgrade. But is it worth the burden that would be imposed on users of dormant/defunct projects? Also, although the forwarding mechanism would impose a slight performance cost on every variable access, this penalty would only be substantial for variables that are actually obsolete. Still it might be unacceptable. > - Actually remove the function/variable from the non-released code. > I.e. remove/deactivate the functions/variables from trunk during > development but put them back in when we start pretesting. Yuck. Sounds like a wonderful way to lengthen the pretest period, to me.