Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 28844 invoked from network); 20 Mar 2002 04:42:00 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 20 Mar 2002 04:42:00 -0000 Received: (qmail 5631 invoked by uid 97); 20 Mar 2002 04:42:09 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 5570 invoked by uid 97); 20 Mar 2002 04:42:08 -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 5545 invoked from network); 20 Mar 2002 04:42:07 -0000 Message-ID: <001501c1cfc9$bc6694a0$9401a8c0@21stcentury.net> Reply-To: "Morgan Delagrange" From: "Morgan Delagrange" To: "Michael A. Smith" , "Jakarta Commons Developers List" , "Morgan Delagrange" Cc: "Henri Yandell" References: Subject: Re: [collections] ReverseComparator Date: Tue, 19 Mar 2002 22:43:08 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ----- Original Message ----- From: "Michael A. Smith" To: "Jakarta Commons Developers List" ; "Morgan Delagrange" Cc: "Henri Yandell" Sent: Tuesday, March 19, 2002 6:22 PM Subject: Re: [collections] ReverseComparator > On Tue, 19 Mar 2002, Morgan Delagrange wrote: > > If you like. Either we add setComparator/getComparator, or we remove the > > undesirable no-op constructor. If it were me, I'd just do the later, but > > I'm not in the "make every class a bean" camp. > > I disagree. a no-arg constructor and dynamic instantiation of the > comparator may be useful without a get/setComparator mechanism. For > example, consider an application that allows you to specify a comparator > in a configuration file while it will use for a particular application > specific task. The config fail may just ask for the comparator class > name, and the app can instantiate an instance of the comparator to use. I don't dispute that the new no-op constructor is an improvement. :) But if we're going to fix it, let's fix it right...I'm not sure we've gone far enough yet. Right now, the only use for that no-arg constructor is to provide functionality identical to Collections.reverseOrder(). That doesn't seem very useful at all. If you want to support bean-like construction, then let's add getter and setter methods; if not, then let's dump the no-arg constructor entirely. This middle ground seems inadequate. I'd just pick one, but I don't want to tick anybody off. Here's my case for just removing the no-arg comparator. 1) Bean-like construction of a Comparator seems unimportant as a feature. 2) If only the constructor can set the comparator that's reversed, it's not possible to do something naughty like changing a comparator after it has already been assigned to a SortedXXX. If folks really want no-arg, then let's at least add a setter method. For me, that option is a distant second, but livable. > get/setComparator methods are really only useful for altering the > underlying comparator once the reverse/inverse comparator has been > constructed. I think this is bad because the underlying comparator is > part of the functionality, and providing modification of it thus changes > the functionality of the reverse/inverse comparator. That doesn't seem > like an appropriate attribute modification. Definitely agree. I'd prefer to not have getter/setter methods. > Since there's been a bit of discussion on the issue, and I haven't really > heard any objections to my diff (fixing the comparator with respect to the > comparator contract), I'm going to check that in. I'm also going to check > in the argument swap rather than multiplication. We can continue > discussion on the rename and whether or not to have a no-arg constructor. -0 for a no-arg constructor. -1 for the name change, only because it has the same connotation as and shares terminology with Collections.reverseOrder(). Might as well be consistent. If the term seems awkward, then a more specific definition in the Javadoc should suffice. > regards, > michael > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: For additional commands, e-mail: