From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31104 invoked by alias); 9 Sep 2004 20:26:07 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30925 invoked from network); 9 Sep 2004 20:26:04 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 9 Sep 2004 20:26:04 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i89KPwS2000802 for ; Thu, 9 Sep 2004 16:26:03 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i89KPr300508; Thu, 9 Sep 2004 16:25:53 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id DF16928D2; Thu, 9 Sep 2004 16:25:48 -0400 (EDT) Message-ID: <4140BC4C.50003@gnu.org> Date: Thu, 09 Sep 2004 20:26:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040831 MIME-Version: 1.0 To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [patch] Deprecate XM_FILE and TM_FILE References: <41376681.4050203@gnu.org> <01c4912b$Blat.v2.2.2$2bea1980@zahav.net.il> <413898FB.7080502@gnu.org> <01c49276$Blat.v2.2.2$c81daa00@zahav.net.il> <4139D06B.5060902@gnu.org> <01c4929c$Blat.v2.2.2$3333c200@zahav.net.il> <413A277E.3060700@gnu.org> <01c492ff$Blat.v2.2.2$4fec0480@zahav.net.il> <41407F45.2090401@gnu.org> <01c496a3$Blat.v2.2.2$8948c5e0@zahav.net.il> In-Reply-To: <01c496a3$Blat.v2.2.2$8948c5e0@zahav.net.il> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-09/txt/msg00152.txt.bz2 >>> Now if I were to try to either: >>> >>> - deprecate or delete GDBINIT_FILENAME without a replacement >>> - delete XM_FILE without eliminating DJGPP's dependence >>> >>> then you'd have strong grounds for complaint. > > > Deprecating XM_FILE means it will be deleted in the next major > release. So I'm complaining now to prevent the more-or-less automatic > deletion of anything that matches the regexp "deprecated.*" > (case-insensitively) in the near future, when it would be too late to > complain. This isn't correct. Deprecating something does not mean that it will automatically be deleted in the next major release. We've still got stuff that was deprecated in '99! >>> I think you're asking who will cut the code necessary to acheive >>> each of: >>> >>> - eliminate/replace GDBINIT_FILENAME from xm-*.h >>> - eliminate/replace CRLF_SOURCE_FILES from xm-*.h >>> - eliminate/replace DIRNAME_SEPARATOR from xm-*.h > > > Yes. And I also request that the replacement for these xm-*.h > definitions be in place _before_ we deprecate XM_FILE, because in my > book, a feature that is being actively used cannot be deprecated. Java defines deprecation as: http://java.sun.com/docs/books/tutorial/post1.0/converting/deprecation.html > What Does Deprecation Mean? > > You might have heard of the term "self-deprecating humor." It describes humor that minimizes one's own importance. > > Similarly, when a class or method is deprecated, it means that the class or method is no longer considered important. It is so unimportant, in fact, that it should no longer be used at all, as it might well cease to exist in the future. > > The need for deprecation comes about because as a class evolves, its API changes. Methods are renamed for consistency. New and better methods are added. Attributes change. But making such changes introduces a problem: You need to keep the old API around until people make the transition to the new one, but you don't want developers to continue programming to the old API. > > The ability to mark a class or method as "deprecated" solves the problem. Existing classes that use the old API continue to work, but the compiler can issue a warning when it finds references to deprecated items. Meanwhile, API documentation can warn the user against using the deprecated item and tell the user how to avoid doing so. To mark API as deprecated, the implementer of the API uses a special tag in doc comments: @deprecated. The task of formally deprecating a mechanism, and the task of eliminating uses are separate, we need to keep them as such. How about we get this in, and then I'll follow up (by 6.3) with patches to finish this (as I said, I suspect I'll be doing the dirty work). Andrew