Maybe I need to think about this deeper (in fact I am sure I
do, you always do), but I didn't mean to suggest that I wanted
two interfaces.

When I said that the data may come from the table or it may
come from input, I meant that it was arbitrary not distinct.
So that, I want it to be generic such that it is one interface
able to handle any kind of data.  Thus, the constuctor is
set to handle an inputed hash.  That hash is checked against 
a "permitted" hash which makes sure that no extra hash values
are added to the object.  The permitted hash does much of what you 
suggest.  It grabs the columns from the table which are allowable.
I simply put this in a seperate private method which I figured 
would make it easier to maintain.  I think this in part addresses Tye's 
concerns which I agree are something to be careful of.

Here is my current constructor:


sub new
  {
    my ($caller, $args) = @_;
    my %memberData;
    my $class = ref($caller) || $caller;

    # grab the fields that are allowed to be member data
    $memberData{'_permitted'} = &_permitted();
    for (keys %$args)
      {
	if ($memberData{'_permitted'}->{$_})
	  {
	    $memberData{$_} = $args->{$_};
	  }
      }
    $memberData{'errors'} = 0;
    my $self= bless { %memberData }, $class;

    # $self->error now contains errors, check before proceeding.....
    $self->_validate();

    return $self;
  }


Does this take care of those issues or am I way off base?  As I 
said, I have made these classes before but usually much more
straight-forward.  This time I want to try and the class so 
that I have the handy OO interface with a class that takes
the data as a parameter because the member data fields will 
be dynamic (or at least I want to be prepared if they are).