Uzytkownik "Daniel Pitts" <googlegrou...@coloraura.com> napisal w wiadomoscinews:1170446407.708622.99960@v45g2000cwv.googlegroups.com...
On Feb 2, 11:40 am, "Marcin" <e...@email.com> wrote:
Hello
There is a very useful functionality, that I think should be implemented
in
TreeSet nad HashSet
that is the method: Object get(Object o).
The method should return the same object from colletion as the parameter
object.
In TreeSet complexity would be log(n), in HashSet would be constant.
With lack of this functionality one must implement collections on maps,
so
the unnecessary and more complex type will be used.
What do you think about this?
Regards
Marcin
What would be the use case of this?
would it return null if the set didn't contain the object o?
Also, this should be in the Set interface, if anywhere.
Whats so hard about using boolean contains(Object o)?
contains does not return object only the information about exisiting of this
object.
Or, are you basically using a Set<SomeTypeThatHasBothKeyAndValue>?
In that case, you SHOULD use a Map. Thats the whole point on maps, is
that you can key on the value.
We can said that almost every class that have implemented the method equals
have both keys and values, where the keys are fields used in the method
equals. But we do not use maps always.
Maps concept should be hide from developer where it is not needed. Maps
concept does not exist in this case directly, and should be ommited in my
opinion. The sets concept is clearer.
Oh, almost forgot to mention. HashSet is backed by a HashMap, so
you're using a map anyway. Why not just use a Map if thats what you
really want?
When you want to use Maps instead of sets you should create the other class
for key objects, when you are dealing with very huge data, space consumed by
key object could be very big. And we have redundant data. The solution like
dividing class into two class: key class, and value class breaks the class
concept. Why used more complicated data type, when adding get method is not
hard, because of sets implementation based on maps?
Marcin
implementations of the "Set" interface, including third-party code.
usecase, which is "query-by-example". And, low-and-behold actually has
a Map isn't more complicated than a Set to use. I also gave you code