Namespace for common datatypes

2003-10-15 Thread Michael A Nachbaur
I've been refactoring an intranet application to use Class::DBI, and one of 
the things that's been bothering me has been the inconsistant perl modules 
for different data types (e.g. dates/times, currancy, intervals, ethernet 
addresses, et al).

I'm going to be creating a set of wrapper classes that presents a common 
interface to some of the CPAN modules that supports the above datatypes and 
just does the Right Thing.  Instead of placing these modules in my 
project's namespace, never again to see the light of day, I was thinking of 
putting this on CPAN.

I wasn't exactly sure where this should go in the namespace however.  I was 
thinking it might belong under Class::DBI, but this ideally wouldn't be 
specific to Class::DBI.  I was also thinking about putting this in P5EE, but 
that doesn't seem right somehow; the scope of P5EE is too much for me to 
focus on.  With this in mind, before I go too far on my modules, I have the 
following questions:

a) Has anyone done this already?

b) Anyone think differently than I, that this should go in a namespace other 
than P5EE or Class::DBI? (e.g. DataType::Interval, 
DataType::Network::IPAddress, DataType::Timestamp)

-- 
/* Michael A. Nachbaur [EMAIL PROTECTED]
 * http://nachbaur.com/pgpkey.asc
 */

OK, so ten out of ten for style, but minus several million 
for good thinking, yeah? 



Re: Namespace for common datatypes

2003-10-15 Thread Mark Stosberg
 I'm going to be creating a set of wrapper classes that presents a common 
 interface to some of the CPAN modules that supports the above datatypes and 
 just does the Right Thing???. 

Could you say more about what the Right Thing is, or give an example?
That might help the discussion of the appropriate name.

Mark

-- 
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark StosbergPrincipal Developer  
   [EMAIL PROTECTED] Summersault, LLC 
   765-939-9301 ext 202 database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .