I would second the ETL::$Brand suggestion. There isn't necessarily a consensus on how ETL should be done even outside the perl community. I also think ETL::$Brand honors the perl TIMTOWDI culture and that allows for multiple ETL styles with overlapping function.
Jed On Wed, May 4, 2016 at 6:27 AM, Smylers <smyl...@stripey.com> wrote: > 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 >
