Christian said:
i have to admit that i did not read the documentation that carefully.
The same remark appears in TreeSet's class documentation as well; I
cited SortedSet instead to emphasize that the requirement it is not a
quirk of TreeSet specifically. And as I wrote before, the issue is
discussed at some length in the Comparator docs too. I'm not looking to
pick a fight, but I have only limited sympathy for people who do not
RT<expletive/>M. At least the class-level docs and the docs for the
specific methods used, implemented, or overridden. How can you expect
to subclass a class or implement an interface correctly if you do not
know how your class' parent(s) indicate it should behave? How can you
expect to use an object's methods appropriately if you don't know
exactly what they're supposed to do?
actually what i would like to have is an interface as you have in ANSI
Common Lisp. for example have a look at the following two links:
14. Sequences:
http://www-2.cs.cmu.edu/Groups/AI/html/cltl/clm/node141.html
15.5. Using Lists as Sets:
http://www-2.cs.cmu.edu/Groups/AI/html/cltl/clm/node152.html
I don't speak Lisp, but I get the idea.
by letting all of the methods given in the above two references take
addional parameters like :test and :key you actually do not care which
datastructure you have as the underlying, a list, a hashmap, a tree, ...
the functions just do what you want them to do on any datastructure.
If you read the docs for the various Collections classes (or at least
those for the basic interfaces: Collection, List, Set, and maybe Map)
then you might find that Java Collections do much of what you're looking
for. List and Set both extend Collection in such a way that you can use
them fairly interchangeably. The Collections class (note the "s")
offers a variety of methods for Collection instances, some more generic
than others, but none more specific than the basic collection
interfaces. Collection itself defines methods for several of the
operations described for Lisp Sequences, and List defines a few more.
Those defined on Lists and not on Sets are inapplicable to a Java Set
because in Java generic Sets have no defined order.
you do not have to think about a clever way to do something like:
i would have never guessed that the removal of the keys from the keySet
would also remove the elements from the map?? i would have guessed that
keySet returns a new data-structure without any connection to the
original map.
And therein you have touched one of my pet peeves: why are you
_guessing_ about such details? As I have been exhorting our friend
Anony (who started this thread), read the API docs.
but by reading the documentation carefully enough i could have found out:
public Set keySet()
Returns a set view of the keys contained in this map. The set is backed
by the map, so changes to the map are reflected in the set, and vice-versa.
One way a person might come to such a discovery without carefully
studying all the method descriptions of every class and interface might
be something like this:
() I conceive a problem: I want to remove from a Map all of the entries
with keys that appear in some Collection.
() I look to the Map interface for a solution, and find no method that
performs this specific task.
() It seems an entirely reasonable thing to do, however, so perhaps
there is still an easy way to do it. I start looking at the methods that
have to do with keys.
() The keySet() method stands out because it returns a Collection (a Set
in fact). I read the docs for the keySet method, and aha!
If you approach the platform API with the view that it is fairly
complete and flexible then you will be more likely to find what you're
looking for. The Collections classes are an especially good example,
IMO; they have their flaws (some of which are inescapable consequences
of the Java language design), but they are well designed, highly
flexible, and written at very appropriate levels of abstraction.
John Bollinger
(e-mail address removed)