Re: [COLLECTIONS] Comparator observations

["Michael A. Smith" <mi...@iammichael.org>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>