----- Original Message ----- From: "Michael A. Smith" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>; "Morgan Delagrange" <[EMAIL PROTECTED]> Cc: "Henri Yandell" <[EMAIL PROTECTED]> 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
