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? 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.
>
> 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.
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.
>
> 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 :) 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.
Hen
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
