For a module with one essential function, parsing a number into an English string, it does seem excessive. But what if my program already has a get_string() function or an %N hash, and I add this module after the fact? The OO layer protects me from name collisions (and in my example is completely optional). While I might not worry too much about it for Lingua::EN::Numbers, I certainly would worry if CGI didn't offer me a choice-- that module has the potential to export several dozen function names, many of which (in a CGI script) might clash with my function names (poorly chosen names, perhaps).
in reply to Re: Use modules or roll your own?
in thread Use modules or roll your own?
The OO isn't really pointless. It's happening either way-- exporting symbols without being asked to do so is just a sneaky way of concealing it is all. What I've said is that it should be explicit and optional for a module where the instance is really just an instantiation of a machine, rather than an instance of a class with unique properties that would distinguish it from other instances in the same class.
Essentially the instance becomes a shorter way of doing print Lingua::EN::Numbers->get_string(1281), " fish in the seas\n";... which you can also get around by offering the ability to export get_string(). Is there an actual reason for avoiding instantiation of a machine to prevent namespace collision? Or is the objection purely aesthetic?