On Jul 18, Scott R. Godin said:
So, there will be instances where only one user will be handled, and instances
where we'll be sifting through all the users for specific data (email,
snailmail, birthday, anniversary)
I'm leaning towards (per your comments above) the Subscriber::DB holding the
database, with methods to create, lookup and return, alter, and delete a
Subscriber (object), which can then use the methods in Subscriber to format
its internal data however I need it, (possibly as I cycle through a LIST of
returned Subscribers, depending on the lookup request)
I would certainly suggest it. ;) The Subscriber::DB object should really
just be a glorified database handle. It has operations on it -- shortcuts
to SQL queries -- and returns whatever information corresponds to that the
query. The Subscriber::DB should be your gateway to the Subscriber
objects (which are produced by lookups on the table, or by a method call
which creates a brand new entry).
--
Jeff "japhy" Pinyan % How can we ever be the sold short or
RPI Acacia Brother #734 % the cheated, we who for every service
http://japhy.perlmonk.org/ % have long ago been overpaid?
http://www.perlmonks.org/ % -- Meister Eckhart
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
