Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 6996 invoked from network); 24 Jun 2002 22:19:02 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 24 Jun 2002 22:19:02 -0000 Received: (qmail 29654 invoked by uid 97); 24 Jun 2002 22:19:13 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 29638 invoked by uid 97); 24 Jun 2002 22:19:12 -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 29623 invoked by uid 98); 24 Jun 2002 22:19:12 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Date: Mon, 24 Jun 2002 23:18:07 +0000 Mime-Version: 1.0 (Apple Message framework v482) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: [CLI] parse methods with fromIndex and toIndex From: John Keyes To: commons-dev Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.482) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi, There are some parse methods on Options that accept two int parameters, fromIndex and toIndex. These parameters are not used in the code. Can someone let me know why they are there? I don't see the point in providing the user with the ability to decide from what point they should start processing the arguments and at what point they should stop processing them. Can someone provide a use case where this would be beneficial. If there is no concrete reason for keeping this I would like to remove them. I'm +1 for this. The reason I ask is because it will mean that all parser implementations will have to implement these methods. The CommandLineParser interface currently takes a java.util.List parameter for the arguments. I think it is more intuitive that the parameter is a String array, as this makes more sense from a users and from a parser developers point of view (though I doubt there will be many of these). The individual parsers can then decide whether to convert the array into a list. This will be a low impact change. I'm +1 for this also. -John K -- To unsubscribe, e-mail: For additional commands, e-mail: