Return-Path: Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Delivered-To: mailing list dev@ant.apache.org Received: (qmail 34587 invoked from network); 20 Mar 2003 00:51:01 -0000 Received: from palrel12.hp.com (156.153.255.237) by daedalus.apache.org with SMTP; 20 Mar 2003 00:51:01 -0000 Received: from gort.cv.hp.com (smtp1.cv.hp.com [15.0.200.101]) by palrel12.hp.com (Postfix) with ESMTP id 7CBB91C00A8E for ; Wed, 19 Mar 2003 16:51:06 -0800 (PST) Received: from iseran.com (ranier.cv.hp.com [15.87.25.18]) by gort.cv.hp.com (Postfix) with ESMTP id 9A7C51FE23 for ; Wed, 19 Mar 2003 16:51:05 -0800 (PST) Message-ID: <3E7910A6.6030209@iseran.com> Date: Wed, 19 Mar 2003 16:51:50 -0800 From: Steve Loughran User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030302 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ant Developers List Subject: Re: [VOTE] JDK 1.1 support References: <208C46AF9D86D31188FD006008298C4103C60FDA@nts-049ha-002.interne.impress.de> In-Reply-To: <208C46AF9D86D31188FD006008298C4103C60FDA@nts-049ha-002.interne.impress.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Christoph Wilhelms wrote: > Hi Costin! > > >>+1 on your comment ( and a preemptive -1 on changing any >>public method that >>uses Hashtables to use Maps - "just because we can" :-). >>Using Maps in new >>code or tasks should be fine. >> >>Refactoring some of the introspection code - like support for >>context class >>loader or jdk1.2 methods - is worth it ( IMO ), as it'll make the code >>easier to understand. > > > I do not want to sound too arrogant, but IIUC "refactoring" implies the > stability of interfaces - otherwise it would change/break the interface and > it isn't refactoring anymore ;). Just if I understood Martin Fowlers > Refactoring book correctly *g*! Putting my 'I used to use formal methods' hat on, interfaces as defined by Parnell in 1974 were the combination of signature and semantics, not just the binary signature that is taken as 'interface' in Java and similar languages. Refactoring in the Ant context strives to retain the same behavior against the specification, that specification being written in Junit test cases and the Gump builds. A lot of refactoring changes the internals of stuff around. Look at the recent CVS diffs for the .dotnet packages if you want to see rampant IDEA refactor buttons at work. I do, you see, think it is very cool indeed, especially the minimal side effect commands in IDEA. Many of which (pull member up, push member down) do change the signatures of classes. In an OSS project, we have to deal not only with the external behaviour of the app, but with people who have subclasses our classes, and to a lesser extent people who are branching from the main CVS tree. If we refactor manically the moment Java1.2 is allowed, we will branch too rapidly from the 1.1 codebase to be be able to share patches across the source trees. This doesnt mean I am not in favour of refactoring stuff, just that we dont make it extra hard for us to do the 1.5.x maintenance as we do so.