my point is that a single object instantiation and method call can be something trivial - e.g. adding two numbers...

I guess if you need a script to add 2 to 400, then that is fine.

But what makes Math::BigInt's use of OO useful, is that it provided substantially more than 1 method.

More to the point, it uses the OO methodology to provide facilities that would be difficult if not impossible to provide any other way: namely, the ability to switch transparently between different back-ends, that allow the user to choose their priorities. If they need more speed than the pure Perl implementation provides, they can underpin it with Math::GMP (assuming it builds on their system). Still too slow, but they are prepared to trade some accuracy, they can stick Math::Pari in there instead.

That is well-architected, well-implemented, useful OO Not pseud-OO for its own sake.

(If you don't like the Apache example, then pure Perl Web servers such as Starman are usually not much more than an instantiation plus method call.)

A module -- regardless of what it does -- that provides nothing but a constructor and a single method is a fatuous use of OO: Ie. pseud-OO. A completely, useless, pointless, puerile use of OO for no benefit.

But even then, if the constructor consists of blessing a hash with some data in it, where's the harm. It costs nothing.

But pulling 288 modules into memory to provide pseud-OO -- OO for no benefit or purpose beyond the dogmatic assumption that "OO is better" -- is using OO as nothing more than a fashion accessory. Like a Diamond Encrusted iPhone or a Gold-plated iPad. It's just plain nuts.

App::Reprove does a different task. App::Prove runs one or more test cases that are on the local disk. App::Reprove takes the name of an already installed module, finds its test cases on CPAN, downloads them into a temp dir and runs App::Prove on them.

Exactly! If the module is already installed, so are the tests. Downloading them again is pointless. And using pseud-OO to do it even more so.