[jdom-interest] Bit masks in ContentFilter

[Bradley S. Huffman]

I think that the javadoc example using bit-masking should be taken out
for the reasons below.  The prefered way should be to create a new
ContentFilter then use set*Visiable methods to modify it. Come to think of
it, I'd probably remove two of the constructors (leaving just the no-arg
constructor).

Originally all the bit-masking stuff was private, then I added getFilterMask
and setFilterMask with the idea that another filter or piece of code would
want fast access to the mask without having to use a bunch of 
is*Visiable-style methods. I'd leave them public.

Brad

Elliotte Rusty Harold writes:

> The bitmasking approach of ContentFilter strikes me as very un-OO. Even 
> if we use it internally for performance, I'd prefer it to be completely 
> private. i.e. all the details of the masking would be completely private 
> or at worst package-private. The clean method interfaces should be 
> enough. Bitmasking and the like is an implementation detail the client 
> programmer should not concern themselves with.
> 
> As a side note, I've been seeing in my classes lately that my students 
> are less and less likely to be familiar with bitwise operators of all 
> kinds. This was important stuff in the C-centric world of a decade ago, 
> but now it's mostly arcana familar only to old farts like me. Yes, it 
> exists in some classes in the JDK such as ImageObserver, but these are 
> all old classes written way back in Java 1.0 before the programmers at 
> Sun had fuly transitioned to the Java way of doing things. I classify 
> this stuff along with named constants in lower case as vestigial relics 
> of C.
>
> Since the ContentFilter class is very new, we probably wouldn't hurt 
> anyone too badly by removing public access to these fields, and we'd 
> simplify its API considerably going forward without losing any 
> functionality. Indeed, we'd be opening up the possibility to discover 
> newer, faster implementations in the future.