
Data::Maker - Simple, flexibile and extensible generation of realistic data

Data::Maker does not know why kind of data you need, but it will help you make lots of it.

And if you happen to need one of the various types of data that is available as predefined field types,
it can be made even easier.

The big difference between Data::Maker and modules you may have seen before is that Data::Maker 
is specifically designed to make it easy for you to generate realistic random data.

ROADMAP

* Some type of "Person" class that would automatically `use` all of the 
  Person subclasses and generate all fields related to one Person while taking into account
  other fields of the same person (if that makes sense)
* Data::Maker::Field::Company: to generate realistic, but not necessarily real, company
  names, based on multiple word lists
* Data::Maker::Field::Address::Street:  to generate realistic street names, based on multiple
  word lists
* Data::Maker::Field::PhoneNumber: to generate realistic phone numbers, preferably for multiple locales 
* I wonder why most of the code needed by the Format class is in Data::Maker::Field?  I need to answer
  that question of fix the problem.
* I also wonder why I made the decision to make fields() take a list of hashrefs instead of list
  of blessed Field objects.   I'm pretty sure my first stab at this took blessed objects and there
  was some reason that I went to this.  But I'm sure somebody will eventually ask the question, so I would
  like to know the answer.  This is something I should maybe get to the bottom of.
* There is likely some usefulness in the ability to have Data::Maker generate something other than
  perfectly-clean data.  A defined amount (or a random amount) of dirty or incomplete data is something
  that might make some sense, for the purpose of testing scripts whose job is to identify bad data.
* I would like to make Data::Maker::Field::Person a separate distribution, particularly because of the
  Gender class's dependency on Text::GenderFromName.  I think a reasonable rule of thumb about what to 
  include as a built-in field and what to make a separate package is any field class that has an
  external CPAN dependency.  For example, Data::Maker::Field::Currency is a perfectly-valid built-in
  class, but when I decided to outsource the work to Data::Money and its dependencies, I had to 
  either commit all Data::Maker users to currency dependencies or commit myself to maintaining a separate
  distribution (and inconveniencing Data::Maker users who want to use the Currency field by making them
  download a seperate distribution).  Obviously there's a lot of philosophy involved here.
* Using that same rule of thumb, Data::Maker::Field::DateTime should also be a separate distribution.

