use Lingua::EN::Numbers;

   my $n = new Lingua::EN::Numbers;
   $n -> parse (1281);
   print $n -> get_string, " fish in the sea.\n";
[download]

   use Lingua::EN::Numbers::Easy;
   print "$N{1281} fish in the sea.\n";
[download]

Abigail

The problem there isn't a "pointless use of OO", but rather an API that isn't very sensible. One is tempted to ask why the module has an interface that forces a user to create an instance, give the instance a number, and then retrieve a string from the instance when a simple class method exported would have worked more easily. I mean, then I have to remember whether the current number in the instance is the one I want-- which is the sort of "internal state of object" knowledge the rest of my program shouldn't have to be thinking about. It would bother me a lot less if the module had fewer steps:

use Lingua::EN::Numbers;
my $n = Lingua::EN::Numbers->new;
print $n->get_string(1281), " fish in the sea.\n";

#or

use Lingua::EN::Numbers qw(get_string);
print get_string(1281), " fish in the sea.\n";
[download]

With this sort of interface I have a choice of whether or not to pollute my namespace with a function name (like with CGI.pm, I prefer not to attempt to export all those HTML markup tags as function names).

One is tempted to ask why the module has an interface that forces a user to create an instance, give the instance a number, and then retrieve a string from the instance when a simple class method exported would have worked more easily. I mean, then I have to remember whether the current number in the instance is the one I want-- which is the sort of "internal state of object" knowledge the rest of my program shouldn't have to be thinking about.

This is exactly what I mean by "pointless OO". Even your suggested class method is "pointless OO" to me. It doesn't buy you anything, except additional clutter.

Abigail