: > so that BitDocSet could continue : > to have deprecated constructors that take in a BitSet (and could continue : > to impliment getBits():BitSet) : > Those should be fairly straight forward right? ... : : I had considered it, but I think the dangers might outweigh the benefits. : I'd almost rather have someones code break and have an easy way for : them to fix it rather than silently slow it down by an order of : magnitude. : : > (were you planing on changing the declaration of DocSet.getBits() to : > return OpenBitSet?) : : Yes, I think so.
Hmmm ... yeah, I see your point about it being better to break the code in a way that's easy to fix then have a super slow translation that might take place a lot. ok... I'm on board with changing getBits and the constructor for BitDocSet to replace all BitSet refrneces with OpenBitSet -- but i'd still like to add those static utilities so people who might have a specific reason to keep using BitSets will have a way to do it. : It's a library developers class... too many times I have wanted to do : something as efficiently as something in the Java standard library, : only to find out that the needed methods are package protected. In : this case, the downside is that it messes up the JavaDoc a bit though. : Still, most users shouldn't be even looking at this class right? they can be protected without being package protected ... or they could be public in an even lower level class (a static inner class maybe?) .. but my main motivation for mentioning it was to try and reduce hte amount of confusion when people look at the BitSet API compared to the OpenBitSet API ... we want them to look as similar as possible right? -Hoss
