[Melbourne-pm] Invalid use of Exporter as a parent of a class

Robert Norris rob at eatenbyagrue.org
Tue Nov 27 23:48:16 PST 2012

On Wed, Nov 28, 2012 at 05:47:54PM +1100, Bradley Dean wrote:
>   # Bad code, don't inherit from Exporter in a class
>   package My::Class;
>   use base qw(Foo Bar Exporter);
>   ...

(Well I'd argue against multiple inheritance too, but that's a separate

I'm of the opinion that your interface is either OO, or
functional/procedural/"exporty". You shouldn't mix both unless you've
got a really unusual use case (that I can't think of right now). And if
you're not sure, then you don't.

> I can't think of any good reason to do this - but my
> partner-in-discussion has invoked "Damian Conway's methods" (Hi
> Damian, sorry to cause teeth grinding if this does so) so I thought
> I'd see if I was missing something.

I hope there was an actual argument and not just "Damian said so."
Otherwise: http://yourlogicalfallacyis.com/appeal-to-authority

Not that I don't love Damian, of course! ;)

> To my mind the only reason that someone would be tempted to inherit
> from Exporter in a class was if you also wanted to export functions -
> and even then the problems of then creating invalid inherited
> 'methods' from Exporter would make this a horrible solution.

If I really really REALLY wanted to do this then I'd use something like
Sub::Exporter, which doesn't require inheriting from something else. But
you'd need some good protections in place to make sure the exported
functions aren't called as methods (or do the right thing if they're
some sort of dual-use thing).

But really, this is smells. Just make two modules and import them
explicitly. You can't go wrong by spelling out weird stuff.


More information about the Melbourne-pm mailing list