http://qs1969.pair.com?node_id=411234


in reply to RFC: Module::Stubber

This is interesting. It reminds me of Test::MockObject and the more recently uploaded Test::MockModule in functionality, but for more general purpose use. I do have a few comments though.

To start with the name is horrible. "Stubber" is just a weird word and you are probably better off just using Module::Stub which is not yet taken.

Second, since use statements run at compile time, I would suggest offering an alternate interface for compile time stub-ing. Something like this.

use Module::Stubber ( 'Foo::Bar' => {         new => sub { bless {}, $_[0]; },         stringify => sub { "$_[0]"; }   });
The code to do so would be simple enough.

Also I would be sure the stub module is properly added to the %INC hash, otherwise require and use will try to load the real module. (you may have already done this, but you didn't post code, so I don't know).

Your description describes a number wonderous possibilites which your module opens up to it's user (hooking into CPAN, alternate @LIB directories, etc). I would create some of those possibilities, either as subclasses of your module or as plug-ins of some kind. Otherwise they are just empty promises. Doing so will also serve to illustrate the use of your module far better than any textual description can. It will also increase the usefulness of your module to a larger audience for whom writing such code is out of their range of skills.

-stvn

Replies are listed 'Best First'.
Re^2: RFC: Module::Stubber
by rinceWind (Monsignor) on Dec 01, 2004 at 11:26 UTC
    Thanks for the feedback. Perhaps Module::Stub is a better name. I also like your idea for using importer semantics instead of calling stub.

    I was aware of Test::MockObject, but not MockModule. However, these are tools for writing tests; I intend Module::Stub to be more general purpose, and useable in production code.

    Also I would be sure the stub module is properly added to the %INC hash, otherwise require and use will try to load the real module. (you may have already done this, but you didn't post code, so I don't know).
    This depends on the circumstances. I am intending to stub when the module is not installed on the target system, so the 'real' module won't be there anyway. But a lot depends on how Module::Stub is going to be used.

    Regarding the status of the module, I have not written any code yet, just the POD sections I posted in the root node. I do feel that there is sufficient interest here, and I will spend time on it and release the module. I will address the API issues of subclassing or plugins as I develop it. I also agree with your last sentence and revdiablo's comment - I want this module to be accessible to a large audience, which does not have a grasp of Perl's arcane features, such as symbol tables, coderefs in @INC, the %INC hash, etc.

    --
    I'm Not Just Another Perl Hacker

      I was aware of Test::MockObject, but not MockModule. However, these are tools for writing tests; I intend Module::Stub to be more general purpose, and useable in production code.

      At the moment Test::MockModule is pretty generic despite the namespace. It doesn't include any test functions right now. And if it did, they'd be optional so you could still use it in production code.

      See also Sub::Override, which is very similar to T::MM. The main differences are that T::MM allows you override subs that didn't previously exist, and inherited methods. And Sub::Override works on multiple packages, whereas T::MM only operates on one package per object

      -- simonflk