In this case it's not an OO module, but in the past I have had the pain of switching back/forth from different implementation namespaces. I agree this is a good solution in that case. Not disimilar from the scenario davido mentions where the PP version uses the _XS version if it's available (thus giving one namespace for the user to use) with a use 'no_xs' etc. to force the PP version. Like I said, this particular module isn't OO, but I'm going to think about this some more since some OO XS cpan modules appear in my future and I'd like a clean solution.
in reply to Re: On naming of XS extension modules
in thread On naming of XS extension modules
What would make this even better is if the root module exported tests. Of course there's no easy way to do this with stuff in the .t directory, so the module will have to install something (probably .pm modules) that the two implementation classes could use for the shared tests. This has the distinct negative of permanently polluting the user's machine - does anyone have a better idea for how to share tests across cpan distributions?
I *think* in your discussion here you're assuming both PP and XS versions in the same distribution. I prefer to have them separate for two reasons - one it allows different authors (in many cases the original author has no appetite or ability for XS, and the author of a few XS speedups isn't interested in maintaining the whole distro even if the original author was happy to give it up). The other reason mentioned by davido is in the case of things like shared hosting, admins are going to refuse anything that even smells of XS (even if it has some fancy non-standard install process that can be instructed to skip it).