jettero has asked for the wisdom of the Perl Monks concerning the following question:

I've made a module, that I'm using successfully. CPAN doesn't really list the module because I gave it a really stupid name.

It's the FoxPro::DBF module listed on my site here. It actually does read DBFs now, and I'm working on getting it to read the IDX and CDX index files.

Since the poor thing is in early development, it hadn't bothered me much, but I wondered if you fine folks would be willing to help me pick a less stupid name?

It doesn't work with DBI at all, though that is an end goal, because DBI feels to sql centric and I have no intention of authoring an sql engine. I was looking through the stuff up there and thought DBD::FoxPro::DBF didn't sound right.

I'm totaly at a loss, but I figure there's people that would use it if they could find it.

Replies are listed 'Best First'.
Re: Foxpro DBF module with a stupid name
by pfaut (Priest) on Feb 08, 2003 at 17:06 UTC

    Since your module isn't providing a backend for DBI, it probably doesn't belong in the DBD namespace. If you will have separate modules for the DBF, IDX and CDX files, I would go with DB::FoxPro::{DBF,IDX,CDX} but provide a user interface that brings them all together in DB::FoxPro. If it's all in one module, I would recommend DB::FoxPro.

    You might get more ideas at http://search.cpan.org by drilling down into the sections that provide similar functionality.

    ---
print map { my ($m)=1<<hex($_)&11?' ':'';
$m.=substr('AHJPacehklnorstu',hex($_),1) }
split //,'2fde0abe76c36c914586c';

    [download]
[reply]
[d/l]
      Wow! This seems just about right. I find it quite exciting really. I'll have to look at the Xbase stuff yet -- to see if I should just give up -- but I bet this is the way to go.

      thanks. :)

[reply]
Re: Foxpro DBF module with a stupid name
by agentv (Friar) on Feb 08, 2003 at 18:49 UTC
    ...actually, don't give up. Just *DO* look carefully to see what else already exists in the area that interests you and try to see where your knowledge adds to the pool.

    There may still be some areas (particularly with respect to handling indexes) that needs some work and you can participate there with widespread blessing. Or, if you find that you can build extensions to existing modules that handle FoxPro anomalies explicitly, that would be good.

    And lastly, if you feel that what you want to do represents an improvement in either performance or ease of use, then you could open a dialog with existing module authors about contributing to their modules or write one of your own that implements the improvements.

    It's true that there are too many modules in CPAN already for most people to keep track of, but most of us know how to search and drill a little when we need to figure out what to do. And as counterpart to the overlap in Perl module space, there are many individuals here who exhibit the "There Can Be Only One" mentality which in my opinion abandons the TMTOWTDI philosophy. In the final analysis, simply try to think of it in the same terms you would if you were filing a patent. First, research prior art to be sure that you're suggesting something that doesn't already exist. If you do that, you'll soon be an "inventor." ---v

    ...All the world looks like -well- all the world, when your hammer is Perl.
    ---v

[reply]
Re: Foxpro DBF module with a stupid name
by Nitrox (Chaplain) on Feb 08, 2003 at 17:40 UTC
    Did you post your question to the groups/mailing lists as suggested in the PAUSE documentation?

    Please, talk to other people (comp.lang.perl.modules, modules@perl.org or any mailing list that fits your problem domain) before you decide upon the namespace you're going to use for your module.

    I've found the folks in comp.lang.perl.modules to be quite helpful.

    -Nitrox

[reply]
Re: Foxpro DBF module with a stupid name
by cchampion (Curate) on Feb 08, 2003 at 16:56 UTC
    In which respect is your module superior to DBD::Xbase ?
    I couldn't see by myself, because the file in your site is empty :(
[reply]
      Well.... your reply certainly explains all my minus votes.

      :)

      Answer:

      I doubt it's superior. I only doubt it because that module already exists. I'm going to look at it and possibly throw out what I've done so far...

      Though, I would like to point out that dbase dbfs and foxpro dbfs are quite a lot different. Mine is uniquely foxpro based... and I'm presently working ont he index CDX format which should be a huge search advantage as my DBF readers is presenly quite slow for large tables.

[reply]
      empty?

      Yes, that explains a lot too!

      Omg, I've been publishing a blank tgz. *rofl* I suck x2 double extra.

      Well, that's fixed. That's probably the whole reason it didn't show up on CPAN too. How embarassing.

[reply]
Re: Foxpro DBF module with a stupid name
by bart (Canon) on Feb 08, 2003 at 22:46 UTC
    Other people have spoken out some of my concerns, so I won't come back to those. However, I am intrigued by certain minor aspects of your little project.

    Most of all: you plan on working with relational databases, and you don't want to work (too closely) with SQL? Eh... OK... so what is your idea for doing work with such a database, then?

[reply]
      Heh. AFAIK, SQL was added to foxpro much later... the early versions did not have sql in it at all.

      (re-written in the face of downvotes):

      Many of my co-workers are working to remove sql from their apps entirely. They feel that anything you can do in sql can be done better with while loops. The way foxpro is layed out, your .prg apps are actually server side stored proceedures (from a mysql perspective).

      In fact, one of our guys showed me that he can always re-write an SQL code block faster using while loops. So, since I have no interest in writing an SQL engine, and since foxpro didn't have SQL originally anyway...

      Maybe I didn't understand your question.

[reply]

Back to Seekers of Perl Wisdom