Robert Wohlfarth writes: > I'm weighing 3 ideas... > 2. Create a top-level namespace for ETL. > > Idea 2 looks like so... > * ETL > * ETL::Extract > * ETL::Extract::Excel > * ETL::Extract::DelimitedText > * ETL::Extract::XML > * ETL::Load > * ETL::Load::MSAccess
Not necessarily. That would be effectively claiming the ETL:: namespace is for your suite of modules. An alternative would be to create the ETL:: top-level namespace and then put your framework under another level of hierarchy there, leaving space for other ETL modules to share ETL::. As in: • ETL::$Brand • ETL::$Brand::Extract • ETL::$Brand::Extract::Excel • ETL::$Brand::Extract::DelimitedText • ETL::$Brand::Extract::XML • ETL::$Brand::Load • ETL::$Brand::Load::MSAccess — where $Brand is a word/phrase of your choice (either just a fanciful name you like, or one you think sums up your particular ETL module suite over other (potentially yet to be written) options. > #2 is short and sweet. On the downside, acronyms are context > sensitive. If potential users of your module are likely to know the term ETL and that's something they'd search for, then it's still a useful name. That probably matters more than for somebody outside the field randomly encountering the name of your module being able to tell instantly what it's for. Obviously a name having both of those qualities would be ideal, but at least somebody who encounters the ETL::Taupe::Extract module can look up its docs, whereas it'd be sad for a would-be fan of your module never to learn of its existence. Smylers -- http://twitter.com/Smylers2
