From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Obsoleting more progressively Date: Tue, 2 Nov 2010 10:51:59 -0700 Message-ID: <5CA84AD0DD354DFC824EDEFB230B7B36@us.oracle.com> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1288720395 25653 80.91.229.12 (2 Nov 2010 17:53:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 2 Nov 2010 17:53:15 +0000 (UTC) To: "'Stefan Monnier'" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 02 18:53:09 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 1PDL2i-0004RC-Rh for ged-emacs-devel@m.gmane.org; Tue, 02 Nov 2010 18:53:09 +0100 Original-Received: from localhost ([127.0.0.1]:59116 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PDL2i-0008Rf-AZ for ged-emacs-devel@m.gmane.org; Tue, 02 Nov 2010 13:53:08 -0400 Original-Received: from [140.186.70.92] (port=59067 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PDL2d-0008Ra-0J for emacs-devel@gnu.org; Tue, 02 Nov 2010 13:53:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PDL2b-00051d-I0 for emacs-devel@gnu.org; Tue, 02 Nov 2010 13:53:02 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:62101) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PDL2b-00051Y-AR for emacs-devel@gnu.org; Tue, 02 Nov 2010 13:53:01 -0400 Original-Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oA2HqxEq003753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Nov 2010 17:53:00 GMT Original-Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oA2H7VEb031444; Tue, 2 Nov 2010 17:52:58 GMT Original-Received: from abhmt001.oracle.com by acsmt353.oracle.com with ESMTP id 743109981288720322; Tue, 02 Nov 2010 10:52:02 -0700 Original-Received: from dradamslap1 (/10.159.219.93) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Nov 2010 10:52:01 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Act6qy4AB59OiNbHT82RRs1nOdySsQABi54g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 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:132289 Archived-At: SM> `make-obsolete' and friends are very useful to let us get rid of old SM> features, but even after 10 years of something being declared SM> obsolete, experience shows it's still in use "out there". Don't worry about it "out there". Worry about it only "in here". Worry only about the code that you produce: the vanilla Emacs sources. There are sometimes good reasons why code "out there" can continue to reference constructs that have been declared obsolete. Code that needs to work with multiple Emacs releases can contain such constructs and can even sometimes access some of them during runtime, sometimes even in a version where the construct is obsolete. That's at least possible, given the dynamic nature of Lisp code (including code generation). And it's not necessarily a problem if it happens. And code "out there" can also contain constructs that happen to have the same names etc. as vanilla constructs that have been declared obsolete. There is no way to automatically analyze code (static or running) to determine whether something is actually an obsolete construct and, if so, whether its use is actually problematic. Even when there are _no_ good reasons for particular code "out there" to use an obsolete construct, that does not mean that there is necessarily a problem. And it certainly does not mean that _you_ need to do anything about it, beyond declaring the obsolescence. Please do not even think about imposing runtime "warnings" about things you consider obsolete. So much for what you should not do. What you should do: Make clear what you consider deprecated or obsolete. Make it easy (e.g. compile-time info) for 3rd-party developers and users to find obsolete constructs in their code. That's all. Leave it up to them how to handle those constructs in their code: whether to remove them etc. ST> runtime warnings would severely piss off users (...), enough so ST> that actively maintained packages would quickly upgrade. What a wonderful approach that would be.