Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Date: Sun, 10 Dec 2006 16:50:16 +0100
From: Dyre.Tjeldvoll@Sun.COM
Subject: Some questions about FormatableBitSet
Sender: Dyre.Tjeldvoll@Sun.COM
To: Derby Development <derby-dev@db.apache.org>
Message-id: <x1o3psaru4w7.fsf@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (usg-unix-v)

There are a couple of things in the implementation of this class that
I just don't understand:

- The doc for the method grow() says:
  "ASSUMPTIONS: that all extra bits in the last byte are zero". But in
  other methods (or() and()...) great care is taken mask out the bits
  of the last byte that isn't part of the bitset. But if it is an
  invariant of the class that these unused bits are zero, it should be
  possible to do most operations byte by byte with no special handling
  of the last byte, right?

- in or() (but not in and() or xor()) an explicit test is done on
  whether the argument of type FormatableBitSet is "instanceof
  FormatableBitSet". Will it not always be? It could have been a
  subclass I suppose, but since FormatableBitSet is final that becomes
  a bit hypothetical.

- A minor nit: This class appears to do a lot of division and
  remainder calculations with powers of 2 (frequently 8). Is it not
  generally preferably to do this with shifts and  bitwise ANDs?

- The algorithm for finding the number of bits set seems a bit
  simple (iterating over all bits, and counting those for which isSet()
  returns true). A simple google search will give a number of ways of
  calculating the number of bits in a byte quickly. Is there a reason
  not to use such an algorithm and iterate over the bytes, rather than
  the bits?

-- 
dt