On Thu, 28 Feb 2002, Morgan Delagrange wrote: > > 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.
Point well taken. > 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. Again, point taken. Soundex should definately go with the soundex stuff. It is specific to that codec. > 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? my iteration example was referring to simplicity of implementation, not applicability to collections. :) regards, michael -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
