Proper use of Sets.SetView..copyInto()
fishtoprecords
It says:
public <S extends Set<E>> S copyInto(S set)
Copies the current contents of this set view into an existing set.
Is the "into set" the argument "set" to the function? or is it the "S"
It almost seems to me that this should be void, what's the return
value?
And more fundamentaly, how do I use it?
Set<T> union = new HashSet<T>();
Sets.union(oneSet, anotherSet).copyInto(union);
Or do I use the returned function?
Ad
// Note: S should logically extend Set<? super E> but can't due to
either
// some javac bug or some weirdness in the spec, not sure which.
public <S extends Set<E>> S copyInto(S set) {
set.addAll(this);
return set;
fishtoprecords
> from the source...
> set.addAll(this);
> return set;
> }
Interesting, This seems to me to be a strange design choice. I'd
either leave the argument Set unchanged and return a new Set,
or have the function be void and clearly note in the API that it has
direct side effects and won't work with an ImmutableSet.
Since its released, too late to change it now.
Kevin Bourrillion
I don't quite follow the Javadocs on this.
It says:
public <S extends Set<E>> S copyInto(S set)
Copies the current contents of this set view into an existing set.
Is the "into set" the argument "set" to the function?
Kevin Bourrillion @ Google
internal: http://go/javalibraries
external: guava-libraries.googlecode.com
Kevin Bourrillion
On Jan 3, 7:19 pm, Ad <ada...@gmail.com> wrote:
> from the source...
> set.addAll(this);Interesting, This seems to me to be a strange design choice. I'd
> return set;
> }
either leave the argument Set unchanged and return a new Set,
or have the function be void and clearly note in the API that it has
direct side effects and won't work with an ImmutableSet.
Pat Farrell
Interesting, This seems to me to be a strange design choice. I'deither leave the argument Set unchanged and return a new Set,That defeats the whole point of this API. We can't choose a Set implementation for you. If we choose HashSet, but you were using TreeSets, or we choose TreeSet but you were using an identity hash set, all hell will break loose. That's why this is all designed the way it is: either just use the *view*, and sidestep the implementation decision that way, or let the user specify exactly what kind of set to copy the results into.
I'm not following you here. We pass in the argument set. You can look at it and use it. Or is there some reflection problem with that.
The prototype would of course have to be a Set, but other APIs in the collection declare that they return a higher level object when they in fact actually return something lower down the inheritance tree. Perhaps that would cause some cast whining in the compiler.
or have the function be void and clearly note in the API that it has
direct side effects and won't work with an ImmutableSet.We clearly noted in the API that it has the *main* effect of modifying the set that is given.
I'm not sure that the "convenience" Set return is all that useful. Back in the olden days, one would chain assignments and function calls, but that style seems to have fallen out of favor. If the function was void, even I would have seen it clearly.
More generally, I love the Collections, but it has taken me a fairly long time to understand what the Javadocs say. Perhaps the authors are so familiar with what it is implemented that they can't see how mortal users can get confused. The whole ImmutableFoo.builder stuff was really hard for me to grok.
Dimitris Andreou
While I understood what Kevin said immediately, I have trouble
understanding what /you/ are saying. Mentioning of reflection
(java.lang.reflect ?), "prototypes" (?), "other APIs in the
collection", or that returning supertypes of the actual returned
values somehow would cause casts and whining from the compiler. There
seems to be some confusion there. The copyInto method has a very
straightforward javadoc - I'm surprized that "an existing set" could
mean any other than the supplied one, since there is no other set in
sight. Nevermind that the next sentence that is even more direct:
"This method has equivalent behavior to set.addAll(this)".
Dimitris
2010/1/4 Pat Farrell <pat2...@gmail.com>:
> --
> Google Collections Library - users list
> http://groups.google.com/group/google-collections-dev?hl=en
>
> To unsubscribe, send email to:
> google-collections...@googlegroups.com
fishtoprecords
> The copyInto method has a very straightforward javadoc
I did not find it straightforward. If I had, I would not have posted
the start of this thread.
It it was declared as void, it would have helped me. Perhaps others
are smarter than I am.
Sam Berlin
Perhaps it would help if the javadocs explicitly explained that the return value is intended to help with method-chaining.
Sam
--
Pat Farrell
Perhaps it would help if the javadocs explicitly explained that the return value is intended to help with method-chaining.
Kevin Bourrillion
@return clause on that method, which might have really helped. It'll
get fixed in Guava.
> --
> Google Collections Library - users list
> http://groups.google.com/group/google-collections-dev?hl=en
>
> To unsubscribe, send email to:
> google-collections...@googlegroups.com
--
Pat Farrell
Whoops -- it was a complete and total oversight that we forgot the
@return clause on that method, which might have really helped. It'll
get fixed in Guava.
Wonderful. Thanks I know that Collections will be subsummed into Guava. But is there any chance of updates to fix bugs or improve the Javadocs between now and whenever Guava condenses out of the Ether?
Kevin Bourrillion
Kevin Bourrillion
Guava is pretty much condensing out of the ether this week.
fishtoprecords
> On Mon, Jan 4, 2010 at 2:40 PM, Kevin Bourrillion <kev...@google.com> wrote:
> Guava is pretty much condensing out of the ether this week.
> Good as my word :-) and look what we even have here:
Wow, that is great. I figured that you would have to wait until all
the press hooplala that is happening Jan 5 at 9AM West coast. or even
after whatever annoucements are coming out at CES. This is very cool.