----- Original Message ----- From: "Henri Yandell" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>; "Morgan Delagrange" <[EMAIL PROTECTED]> Sent: Thursday, February 28, 2002 12:48 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. > > Agreed. Should UrlComparator live with Url? I guess. It seems like a class with limited usefulness, which I tried to flesh out in my email to Michael from a few minutes ago. > The other two I guess are more > Util stuff? Hard to package them. I solved it by having all my comparators > in a compare pacakge. How about I just re-add UrlComparator and NumericStringComparator to Util for now, and we can go from there? > > > > 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? > > PackageNameComparator is pretty specific. I'm happy for this to die. OK, I won't re-add that to Util unless you say so. > UrlComparator, it seems a nice thing to have available as a standard > component. If there were to be a comparator project, then I would > definitely want that in there. > > NumericStringComparator however is something I've often seen people asking > for. It's not a simple implementation (well for the level of people asking > for), so I think it has a lot of uses. It's all opinion though, so I > dunno. To me, this one does stand out from the other two as potentially appropriate. What would a class like this be used for? It still _sounds_ a little application-specific, but maybe not. > > > > Second, none of the Comparators are Serializable. Shouldn't they be, so > > that their corresponding Collections will be serializable? > > I didn't realise this was a feature :) The JavaDocs for Comparator recommend making Comparators serializable unless there's a specific reason not to. Good advice. > How does the serializable > Comparator affect the Collection being sorted? Or is this for TreeSet etc? > If so, then making them Serializable makes tons of sense. Right, you can't serialize a TreeSet (or any Sorted collection) that is ordered by an unserializable Comparator. Otherwise there's no way to order Objects that are added after de-serialization. > Hen > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > _________________________________________________________ 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]>
