Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 97430 invoked from network); 17 Jun 2002 18:59:56 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 17 Jun 2002 18:59:56 -0000 Received: (qmail 26817 invoked by uid 97); 17 Jun 2002 19:00:02 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 26801 invoked by uid 97); 17 Jun 2002 19:00:01 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 26787 invoked by uid 98); 17 Jun 2002 19:00:01 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <20020617185955.99701.qmail@web21210.mail.yahoo.com> Date: Mon, 17 Jun 2002 11:59:55 -0700 (PDT) From: Jonathan Carlson Reply-To: joncrlsn@users.sf.net Subject: Deprecating and Refactoring To: commons-dev@jakarta.apache.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Someone in a Collections thread previously expressed concern over deprecating some things that might be used in production code. What's wrong with that? The whole purpose of deprecation is to allow production code to keep running while informing new development that they are treading on old territory. These utilities will eventually become bloated and difficult to learn if the commiters are afraid of deprecating old code when better techniques come up. My 2 cents, Jonathan ===== Jonathan Carlson joncrlsn@users.sf.net Minneapolis, Minnesota __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- To unsubscribe, e-mail: For additional commands, e-mail: