----- Original Message ----- From: "Michael A. Smith" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>; "Morgan Delagrange" <[EMAIL PROTECTED]> Sent: Thursday, February 28, 2002 12:46 PM Subject: Re: [COLLECTIONS] Comparator observations
> On Thu, 28 Feb 2002, Morgan Delagrange wrote: > > First, I'm not sure all of these Comparators are generic enough to include > > in Collections. ComparableComparator and ReverseComparator seem to be right > > on. NumericStringComparator, PackageNameComparator, and UrlComparator seem > > too specific for Collections though. > > I'm just curious, but why do you feel they are too specific? If someone > whants to create a TreeSet (or FastTreeSet, or pretty much any ordered > set), which contains URLs, a URL comparator might be useful. Why would you want an ordered list of URLs? For display purposes? Or to guarantee that you are not referring to the same file? If that's the case, that's already addressed by URLStreamHandler.equals() which returns "true if the two urls are considered equal, ie. they refer to the same fragment in the same file." If this Comparator is trying to overcome deficiencies in URLStreamHandler, that should be documented in the class. Even if it were the case, I don't believe a Comparator is the right place to address it. Usually, if it makes sense to ascribe order to an Object, that Object implements Comparable. In this particular case, the UrlComparator sorts by host, then path, then protocol, then port. But why that and not protocol, host, path, port? Or why not protocol, host, port, path? URLs don't really have an implicit order, so the UrlComparator is guaranteed to be somewhat arbitrary. > And it > doesn't seem to make as much sense to have the URL comparator in a net > component. > > > It seems that if a Collection or Comparator would seem out of place in the > > JDK, it's not a good candidate for Collections. PackageNameComparator and > > UrlComparator in particular seem out of place. Most comparators are highly > > specific, and comparators are also very easy to write. Consequently, we > > should be wary of which Comparators we include. Bay, would you object to > > removing NumericStringComparator, PackageNameComparator and UrlComparator? > > these comparators (by name only) seem generic enough. They don't depend > on anything other than what's already in the JDK (String, URL). I would > agree that they would be out of place if the comparator was comparing > things that are not in the JDK though. More specifically, a comparator > that depends on something other than stuff in the JDK is probably too > specific and would be out of place. I'm just not sure that theese > comparators are. My objection is mainly their arbitrary ordering. They try to sort Objects that don't have undeniable order. That's why I'd rather see us focus on Comparators that reverse other comparators (ReverseComparator), or comparators that can be used to implement SortedSets or SortedMaps (ComparableComparator). Other possibilities might be classes that let you chain Comparators together, or Comparators that truly address oversights in the JDK. Comparators like the Soundex Comparator also make sense, because Soundex has an implicit ordering (but Soundex is also very specific, and it's more appropriate where it is in Codec.) I'd rather not see us try to ascribe an arbitrary ordering to Objets like URLs and package names. > I'm not sure that "easy to write" is a great argument for excluding them. > If it was, we wouldn't include things like ProxyIterator, > SingletonIterator, or even IteratorEnumeraation. Having the ability to > reuse code rather than just redo it (even if it is simple) is one of the > tenets of the commons project. But surely there's quite a distinction in scope between these classes that deal with iteration in general and a class that only sorts URLs? > > Second, none of the Comparators are Serializable. Shouldn't they be, so > > that their corresponding Collections will be serializable? > > that's probably a good idea. :) Thanks, I thought so too. :) > > 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]>
