Re: Reshaping the modules list: a starting point, help remove the bias.
Hi, within the development cathegory, I think it would be good to separate modules that are for the perl interpreter (debugging, profiling, ...) and other development tools. As an example, I have a module called Devel::Cpp which I put tin the Devel root because I foun no better place (and I didn't ask either :-( but later on I understood that Devel was not for this kind of devlopment tools (I'm still wondering why). Now, there is a new pure perl preprocessor module that I want to use instead for 'cpp', I still don't know where to put it! Cheers, Nadim.
advice needed on Lingua::Identification
Hi, everybody. I'm in need of advice here... I'm putting together some things I have and creating a module named Lingua::Identification. I won't go through details on why should this module be created or anything else (unless someone asks me too) since that has already been done (though not here, I know). My problem is: the module has to retain some information about each known language; this could easily be done by having persist on the module itself... however, I also want the user to be able to *teach* a new language to the module... how should I keep that information? One possibility would be to force each known language to become a module (Lingua:Identification::EN for English, etc)... the downside of this solution is that once I have 50 languages, I'll have 51 modules... :-| Still, CPAN can take care of things for us and install them all without problem... but still, I'm not convinced... It is true that this would allow the user to install only the desired languages and also ease the learning process for new ones... besides, the module wouldn't have to read unnecessary information on startup (there is the possibility of identifying between only two languages, for example, so you don't need to prepare all of them). Another possibility is to have everything in a single file, and allow the user to set up a configuration file himself, which may contain other languages... I don't know what's best... can you help me with this? Can you tell me your opinion? I've done quite a lot of programming in Perl, but I've never upload a decent module on CPAN... I'm trying to do that for the first time, and I don't want to screw things up right from the beginning... Thanks to all of you. Best regards, jac
Re: advice needed on Lingua::Identification
On Thu, Feb 26, 2004 at 04:27:22PM +, [EMAIL PROTECTED] wrote: One possibility would be to force each known language to become a module (Lingua:Identification::EN for English, etc)... the downside of this solution is that once I have 50 languages, I'll have 51 modules... :-| Still, CPAN can take care of things for us and install them all without problem... but still, I'm not convinced... It is true that this would allow the user to install only the desired languages and also ease the learning process for new ones... besides, the module wouldn't have to read unnecessary information on startup (there is the possibility of identifying between only two languages, for example, so you don't need to prepare all of them). Another possibility is to have everything in a single file, and allow the user to set up a configuration file himself, which may contain other languages... I don't know what's best... can you help me with this? Can you tell me your opinion? The answer (in my experience) is it depends. If it's simple to remove the data for each language to a config and use identical logic for all languages, that's usually the way to go. If the logic for each language is different, having separate modules is generally easier to maintain, because changing the logic for one language in an algorithm that supports many languages may break the functionality for the others. This may often seem easier at first, but it doesn't scale too well. There's also a combination of the two. For example, perhaps it makes sense to combine Latin based languages together. Then perhaps you would have: Lingua::Identification Lingua::Identification::Latin and if necessary have an e.g. Lingua::Identification::EN inherit from Latin, if you end up needing to have Lingua::Identification::EN to support English differently than most Latin based languages, where latin based languages are processed differently than other languages. The other thing that's handy about this approach is that you can have common logic in the superclass and only override parts that differ. Hope that makes some sense. :-) Austin
