I don't mind much either. It's just that this sugar method suggests that you have to create a Set<String> on every call, while if we point people to DSFV, people will fins that they can pass String... too.
True, but thats just because DSFV creates the hashset on the fly
Perhaps if we omit the sugar method, people will think that way, and indeed create the object just once. Dunno, it's your call.
Thats true too, because if you reuse the DSFV then the String... method is not harmful since you are only doing it once.
So I think the String... method is ok on DSFV for this reason.
However on indexreader, i think its also ok to have a sugar method with Set, because it just creates a DSFV around that hashset,
so its hardly wasteful.
In other words: Create a Set<String> and reuse your own Set via the proposed sugar method, and I think its fine,
and a lot friendlier. Its not hashing anything. Sure its creating a DSFV each time, but like using a DSFV in any way,
its also creating a Document object each time. If you are really worried about this stuff, implement your own visitor
and don't use Document at all Don't forget we are talking about stored fields too!
And I say keep the String... on DSFV only, but don't add to IR, so we don't encourage lots of wasteful rehashing.