in reply to Re: Re: Use modules or roll your own?
in thread Use modules or roll your own?

   use Lingua::EN::Numbers;

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

[download]
Which is the reason I wrote Lingua::EN::Numbers::Easy where you can do: 
   use Lingua::EN::Numbers::Easy;
   print "$N{1281} fish in the sea.\n";

[download]
to do the same.

Abigail

Replies are listed 'Best First'.
Re: Re: Use modules or roll your own?
by ichimunki (Priest) on Jul 29, 2002 at 15:27 UTC
    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).
[reply]
[d/l]
      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

[reply]
        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).

        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?

[reply]
[d/l]

In Section Meditations