On Thu, Feb 26, 2004 at 04:27:22PM +0000, [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

Reply via email to