Question before I finish readying a patch...

[Rick Berman <ri...@moai.com>]

I finally got a chance to work on teaching Sheet to create a ProtectRecord
by default (with protection off) and HSSFSheet how to provide for turning
the protection on and off.  Before I submit the patch I'd like to run an
issue up the flagpole since I don't have enough familiarity with the POI
code base and the deveopment community (yet?) to be confident of my patch
getting accepted.

I discovered in ProtectRecord that there the getter and setter for the
field_1_protect attribute are asymmetrical.  The getter returns a short and
the setter takes a boolean.  The only POI-internal calls to getProtect() are
in the toString() and serialize() methods.  The short value is needed in at
least serialize() method.  However, it seems better encapsulation for other
clients of getProtect() if it were to return a boolean.  This way the use of
a short field for the storage representation wouldn't so completely invade
the clients of the ProtectRecord.  So, I've started out with the following
choices:

- Change the return type of getProtect() to boolean.
- Define field_1_protect == 1 as true and all else false.
- Changed the serialize() and toString() methods to access the
field_1_protect variable directly rather than use a getter method.

Is this going to be OK?  A little poking around in other Record classes
turned up a couple of other examples.  ProtectRev4Record is consistent with
ProtectRecord.  SaveRecalcRecord is more like what I propose except that the
toString() just emits it as a boolean rather than going through
Integer.toHexString on the short value.

Should I follow the SaveRecalcRecord model completely?

Should I bring along ProtectRev4Record while I'm in the neighborhood?

Thanks for the advice,
  Rick