byterock

So I guess the best thing for me to do now is answer good old question 4 from my last post.

Is this just going to pollute the name-space?

So as I said in my last post DBIx::DA was the name-space I picked some 10 (or is it 11) years ago for my take on the DataAccessor package, and I would agree it does pollute the name-space as like I said it adds nothing to DBI except, some wrapping and SQL generation.

So where to put it?

Well I was thinking under Data:: as something like Data::Accessor.. but when you look at that name-space a good chunk of the modules in there are for working with Data directly i.e. dump it, change it, sanitize it etc. So I think something that just gets data may not work there.

I was thinking of adding it under DB:: but it seems a good number of the mods in that name-space for Database type packages (DB::Ent, DB::Appgen, DB::Introspector to name a few. Oddly the outliers on that name-space (DB::Color, DB::Skip) are the only ones that are suppose to be there as this is usppose to be the name-space for 'DEBUG' mods. There is even a line about it on the 'On The Naming of Modules' page on Pause

You might think that DB is a good name because it's that database portion of your code, but it doesn't say much about what it is doing, and it also happens to be the name-space for the Perl debugger.

Dare I add in another mod there??

Now I could also go with Accessor:: nothing at all in that name-space there are a few Accessors and they are for adding getters and setters to other classes. Me thinks these are fast becoming obsolete with the 'Fields pragma' and Moose and Moo coming into common usage. So maybe here?

I could always go with a cryptic name-space like DASQL or a vanity one like Byte::Rock::Accessor, I would most surly face the wrath of the name-space police or at least some stern comments from Brian D Foy. My only top level name-space Orignal has gotten its fare share of hate over the years. As it is 100% cryptic, unless you speak Joual or Chaouin and even then it is a stretch to link it back to what it does. As well as can imagine nothing ever going under that name-space so it is just dead space on CPAN. Though I do not think it does any harm tucked as it is between Org::To::VCF and ORLite.

I was thinking some thing along the YADA... lines (Yet Another Data Accessor) there are a number of those 'YA's but again I am just obscuring what my module does and there is danger in that. Take the Anansi name-space for example. The first thing that popped into my mind was the spider character from some African folklore, and not object manager so no wonder I have see the odd post by its creator lamenting his choice of name-space.

Leads to a good point that Anansi is a good name for a 'Brand' name-space, we have plenty of those Mojolicious, Catalyst, Mason , Moose etc, so maybe it was well named just somewhat ignored?? Most of these Brand have thier own website (though I think the mason one is down for the count).

In Data Accsessor's case I do not think it will ever become a brand only code to go in other code, but stuff does go under it. I will have to be careful not to select a name-space where my lower levels will conflict with others. I could see myself having a conflict with DB::SQL::Migrations

I have been helped so far by one of my favorite sites Map of CPAN. Which makes looking at entire name-spaces quite simple, just start tying in on the Distro select and you will see the name-spaces come up.

My next act will be to do some posting on PrePan and I was thinking of giving Perl lists a try as well but I think I would get the same response as PrePan and my time is a little limited these day so lets see what happens.