From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15646 invoked by alias); 7 Oct 2004 23:17:37 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 15633 invoked from network); 7 Oct 2004 23:17:35 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org with SMTP; 7 Oct 2004 23:17:35 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 3042B47D98; Thu, 7 Oct 2004 16:17:35 -0700 (PDT) Date: Fri, 08 Oct 2004 07:08:00 -0000 From: Joel Brobecker To: Dave Korn Cc: 'Andrew Cagney' , 'Eli Zaretskii' , gdb@sources.redhat.com Subject: Re: Discussion: Formalizing the deprecation process in GDB Message-ID: <20041007231735.GN1282@gnat.com> References: <20041007180121.GL1282@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-SW-Source: 2004-10/txt/msg00236.txt.bz2 > Erm... things that get deprecated don't often get un-deprecated, do they? No, they are supposed to disappear over time :-). > Wouldn't it largely be a matter of just adding a couple of lines each time > something gets deprecated, just enough to say "All this stuff is now > replaced by the new XXXX mechanism; use XXXXX_do_whatever in place of > deprecated_OLDXXXXXX_do_somethingelse, or see gdb-XXXXX.h for more > information." Or words to that effect. But why is it better to write this in a document that's separate from the code, instead of directly putting this in the code in an absolutely clear way? If you rename the entity that's deprecated from "entity" to "deprecated_entity", then it's pretty clear that you should no longer be using it in new code, or else have a good reason for still using it. Then if you want to know more, you just go to where the entity is defined, and look at the comments there. If you put this in some written document separate from the code, then you have to: change one other file, ask for review from a different maintainer, then commit. And then, you have to constantly remember from the doc which entities are deprecated when you write code and when you review a change. And then you have to remove it from the doc when the entity is finaly removed. In any case, the main debate between Andrew and Eli is not about where to put the information, but *when* it is ok to decide that something is declared deprecated. -- Joel