Items with * are done.

o test for FIELDSEP:
  default, input and output
  supplied as plain string, input and output
  supplied as pattern with missing string version
  supplied as pattern with supplied string version

o Perhaps when a FIELDSEP and FIELDSEPSTR are both supplied, module
  should check to make sure string matches pattern?

o append should have a version that takes a hash

* Should support databases in which fields past the nth are optional

o should have a record ->set method so that fields can be set when
  their names are not known at compile time

* At present, subclassing the record class is impossible, because you
  don't know what to name the subclass.  RECBASECLASS does not solve
  this.  Instead, the ->new call should be allowed to specify the
  class name for the record class, say My::Record::Class.  If the
  author of My::Record::Class wants to set @My::Record::Class::ISA to
  contain UPenn::ISC::FlatFile::Rec, they can do that.

o Clinton Pierce says that ->delete should take a list of records, so
  that one can  $db->delete($db->lookup(...)).

o Scalar context returns from ->lookup and ->c_lookup.  Consensus on
  IRC was that it should return the first matching record.

o The field-access methods are inserted directly into RECCLASS; is
  this appropriate? Perhaps there should be two class parameters: one
  class is the place that the methods are generated into, and one is
  the class from which records are actually created.

o Comment syntax; some of these files have comments in them

* Document Subclasses better.  Document new Subclass->lookup and
  Subclass->c_lookup usage

o Need better control over open routines.  User may need to supply
  already-open, locked filehandle, for example.  How does this work in
  conjunction with the writing strategy of
  create-a-new-file-and-rename-it?  How can we accomodate user locking
  strategies?

o ->new(FILE => undef) returns bad error message: "required key FILE missing".

* The garbage collection problems may be insurmountable.  But even if
  not:

o Suppose one does

        ($a) = File->lookup(color => "red");
        ($b) = File->lookup(color => "red");
        $a->set_color("green");
        is($b->color, "green");

  It should work, but in the 0.03 design it cannot be made to
  work. Add a test for this.
        

* Convert I/O system to use Tie::File instead of doing everything manually

  o Now how do you get back the old semantics that would write a new
    file and then atomically rename it atop the old one?