Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re: On naming of XS extension modules

by afoken (Abbot)
on Oct 06, 2012 at 03:59 UTC ( #997574=note: print w/replies, xml ) Need Help??

in reply to On naming of XS extension modules

Assuming an OO module Foo::Bar, I think the cleanest way would be a frontend with exactly that name. The frontend loads either Foo::Bar::XS or Foo::Bar::PP, then modifies its own @ISA accordingly. By default, the XS should be loaded, with a fallback to PP. There should be a way to force using XS or PP, at least for tests (something like use Foo::Bar -usePP; / use Foo::Bar -useXS;). Shared code and user documentation goes into Foo::Bar, the Foo::Bar::XS and Foo::Bar::PP modules contain only XS methods or their pure perl replacements. Users should not need to know about XS and PP. Code for both should be in the same archive. The installer should make the module work (i.e. install at least frontend and PP backend), preferably fast (i.e. compile and install the XS backend if possible).

For non-OO modules, the backend modules have to export their functions into the frontend, from there, they can be exported to the user code.

A different approach could be copied from File::Spec::Functions, offering an OO interface and a wrapper that offers a function interface, either in a separate module (i.e. Foo::Bar::Functions) or integrated into the frontend module la CGI.


Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Replies are listed 'Best First'.
Re^2: On naming of XS extension modules
by aufflick (Deacon) on Oct 08, 2012 at 04:29 UTC
    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.

    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).

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://997574]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (4)
As of 2018-05-27 04:23 GMT
Find Nodes?
    Voting Booth?