Re: Namespace/advice for new CPAN modules for Thai & Lao

In naming a module like this, which improves the core features of Perl, it can help to think ahead to what else you plan to do with it, and what other modules by other authors you imagine might coexist in the namespace.

For example, if you choose Regexp::Thai, then you are basically accepting responsibility for everything Thai-related in regexes. When someone else wants to add some other feature for using Thai with regexes, they'll now have to find another, less appropriate name. Or, at least, use a sub-namespace, which may be confusing to users when their module is (in most respects) unrelated to yours.

Or, when you want to add other Thai-related regex features, you're going to have to expand that same module (because it has already "claimed" the general name). Those extra, perhaps only loosely related features, will complicate the module's interface, and make it "heavier" to load for your existing users too.

So perhaps Regexp::Thai::Properties would be a better name? That way, you leave the higher-level Regexp::Thai name free...maybe for a later module that loads all the Regexp::Thai::<whatever> modules that you and others have eventually contributed.

And, at the same time, you provide a good naming pattern for others to follow. Perhaps later there will be a Regexp::Thai::Debug, or a Regexp::Thai::Transliterate, or a Regexp::Thai::Common, etc. By creating the namespace, but not pre-empting it, you may eventually encourage a larger, richer and more consistently named ecosystem.

Damian

Comment on Re: Namespace/advice for new CPAN modules for Thai & Lao

Replies are listed 'Best First'.
Re^2: Namespace/advice for new CPAN modules for Thai & Lao by Polyglot (Chaplain) on Mar 23, 2015 at 05:32 UTC
Unfortunately, there seems to already be some significant namespace pollution with reference to Thai-language routines. The two-digit code for the language is "TH" and this has been picked up and used as an abbreviation by at least one module contributor, who has contributed many modules using the name, as an abbreviation for "type handler" (or so it seems). One module contributor appears even to have used the full word "Thai" to indicate the concept of light weight (is that an allusion to boxing?), and the module has nothing to do with the Thai language as far as I could tell, even having looked at the code. So, though there are hundreds of modules that can be found in searching for "Thai" or "TH" on CPAN, only about five actually have anything to do with Thai. We are so far from having any tools in Thai, that it would be a wonder if we could ever run out of its namespace in my lifetime. Most new programmers over here are learning PHP and Java. I wish we did have more who would interest themselves in Perl, and I am trying to interest young people to take it up whenever I have an opportunity. Meanwhile, we have next to nothing. One of the features I was thinking to add would be a Romanization subroutine, which transliterates the Thai to a Roman alphabet, as you alluded to. However, that is not strictly a Regexp issue in any case. The module as it stands has only a few more Regexp-related routines which might be included to make it about as complete as is possible for the Thai language, as I see it. Then what? The regexp engine itself is part of Perl, and works just fine with the addition of these "hooks" that we are adding in this module. This module is so "core" in extending that capability, that it can hardly be more basic than it is. Any additional module might be added to it, and I wouldn't mind at all extending coauthorship to someone else who wishes to help, perhaps with such additions as: Regexp::Thai::LongStrings Regexp::Thai::Romanize Regexp::Thai::Assemble (assuming that the current Regexp::Assemble would not accommodate Thai) etc. Blessings, ~Polyglot~	[reply]
Re^3: Namespace/advice for new CPAN modules for Thai & Lao by captainjames (Novice) on Mar 23, 2015 at 06:03 UTC
The previous discussion has some good advice. The CPAN guideline saying Unicode:: is off-limits applies to CPAN, but if you think your module belongs in CORE then you should email the perl5-porters first and find out. So the steps are: 1) look at the existing Unicode:: modules in CORE and decide if your m +odule belongs in CORE (ask p5p if necessary) 2) if not, pick a namespace and name 3) decide how to generate the CPAN boilerplate files (I use makemaker) + there is a non-trivial amount of work to make a nice CPAN module these days! 4) add some tests 5) try your distro on different machines and when you're happy request + a CPAN account and upload it. 6) wait for CPAN testers to score it and fix it 7) bask in the glory of being a CPAN contributor, along with the other + 10,000 members! :) [download] Later, James.	[reply] [d/l]