Shing Hing Man wrote:
I t would be a useful addition for users who want that functionality with java.lang.Numbers and Strings etc, I agree it probably doesn't need to be a default. It would make a nice utility for the utils section.Mark, Thank you for explaining the cause of the IllegalArgumentException !
I think there is no need to implement a 'default
comparator' to make objects of type like Integer and Long
comparable.
The current version of the class Frequency would meetWell, the issue goes deeper than comparision of Integer and Long, the thrown exception is "obtuse", its unclear from the IllegalArgumentException itself why the ClassCastException occurs until you look at both the implementation of Frequency and its underlying TreeMap. As such I think it is not user friendly. We can do better than this. I agree we can keep the existing expected behavior, but I think the Exception handling should be improved or at least made more descriptive. The issue has to do with the fact that the methods never define the IllegalArgumentException as being "thrown" so user will not get a compilation error if they do not handle it appropriately. In the end the result would be unexpected behavior (no matter how much is documented in the javadoc). The users should be forced to handle the use case by catching the Exception in thier code. This could be either by throwing the IllegalArgumentException (probably a bad choice) or by creating an Exception specifically for this issue and throwing it from our methods.
the needs of most user.
In most situations, your data could be casted to aThe risk with Frequency is that the interface "promotes" heterogeneous and incomparable object usage in the methods that are implemented. For instance:
common type.
public void addValue(int v) {
addValue(new Long(v));
}
public void addValue(long v) {
addValue(new Long(v));
}
public void addValue(char v) {
addValue(new Character(v));
}The fact that the user can call addValue(long) or addValue(int) and then call addValue(char) creates a situation where the interface/implementation itself actually promotes the creation of incomparable objects in the tree. If this is going to be maintained then I would argue there should at least be a comparator that handles these cases.
If a user wants to add data of different types, or
even their own custom type, he/she could implement their own
comparator to
avoid the ClassCastException, hence the
IllegalArgumentException,
when retrieving elements from TreeMap.
I think we can easily improve upon the implementation to manage the contents of the Tree better. A good Comparator can provide us better functionality, better Exception handling is important as well.
-Mark
-- Mark R. Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
