Hi, Eric,

Thanks for the very helpful reply! I think the way you described has a
clean structure and probably easier to manage. I need to do some
reading, though. Also, a problem is that I want to keep my script in a
single file, because it is gonna be used by other people as one of their
many tools. If it has multiple files, some might get lost over time. Is
there any solution that requires only one file but also has a clean
structure of the whole design?

Thanks again!

Steven



-----Original Message-----
From: Eric Wilhelm [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 25, 2004 9:05 PM
To: [EMAIL PROTECTED]
Subject: Re: How do I disable modules in a script (e.g. Inline vs Pure
Perl)

# The following was supposedly scribed by
# Wu, Gang \(Steven\)
# on Thursday 25 March 2004 08:46 pm:

|I am not sure how to do it in the way you just suggested. Can you
|enlighten me a bit, in terms of using separate C and Perl modules?

You've just got to have two modules which declare themselves as the same

package name.  One of these is written purely in perl, and the other
uses 
Inline::C.  You put them in two files which end in .pm and are in one of
the 
@INC directories (or another directory which can be added with 'use lib'
or 
the environment variable $PERL5LIB = 'directory/")

If you want a function-call based interface, you would have to call all
of 
your functions with PackageName::function(), but you might be able to
manage 
it somehow with an import()  sub (or the dirty trick of declaring
'package 
main;')  Point is that I don't think Exporter will work for you if your 
package name does not match your module filename.

The other option is the object-oriented interface, but please don't make

yet-another module with null objects just to use the inheritance 
functionality.

A bit of reading to do:
perldoc -q "how do I create a module"
perldoc -q "How do I add a directory to my include path at runtime?"
perldoc lib
perldoc perlmod
perldoc perlobj

Basically, you have a tree like so:
lib/
|-- MyModule
|   |-- Inline.pm
|   `-- Pure.pm
`-- MyModule.pm

And these three files:
$cat lib/MyModule.pm
package MyModule;

BEGIN {
        eval{require MyModule::Inline;};
        if($@) {
                warn "sorry, no Inline available\n";
                require MyModule::Pure;
        }
}

require Exporter;
@ISA='Exporter';
# note, maybe @EXPORT_OK instead (perldoc Exporter)
@EXPORT = qw (
        add
        );
1;

$cat lib/MyModule/Inline.pm
package MyModule;

use Inline C => <<'EOC';

long add (long a, long b) {
        printf("adding in C\n");
        return(a + b);
}
EOC
1;

$cat lib/MyModule/Pure.pm
package MyModule;

sub add {
        print "adding in perl\n";
        return($_[0] + $_[1]);
}
1;

Then you run this:
  $perl -Ilib -e 'use MyModule;
  print add(7, 9);'
and you get:
  adding in C
  16


This requires three modules, but gets Exporter to work.  Also, you can
define 
always-perl functions in MyModule.pm.  Only put the either/or functions
in 
the Inline.pm and Pure.pm files, since this setup gives you only one or
the 
other.

If you want, you could just do 'use MyModule::Pure' instead of the
require, as 
long as it happens in the BEGIN block *before* you do the require 
MyModule::Inline (since you want the C functions to over-load the
pure-perl 
ones.)

--Eric
-- 
"These crispix get soggy so quickly."
                                        -- Tina Connolly

Reply via email to