lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (05/10/90)
In article <j4ftf4bsg@tmsoft.uucp> mshiels@tmsoft.UUCP (Michael A. Shiels) writes:
: As long as you have source code PERL code have a special version of DBZ with
: different names. The same thing goes for the GNU DBM code and another
: clone which I am trying called SDBM. Seems to be pretty good with disk space.
The real design question here is not whether to allow substituting other dbm's,
which is an ok thing, but whether to allow support for multiple dbm's in the
same executable. Should there be a dbzopen(), and a sdbmopen(), and a
gdbmopen(), etc.?
It seems that Perl would be a great way to convert databases if so.
dbmopen(OLD,'oldfile');
dbzopen(NEW,'newfile');
%NEW = %OLD;
I don't suppose it's possible to intuit from the files which kind of dbm it
is?
Somewhat along the same lines, but not quite, is that I'm going to be adding
a hook for linking in your own C routines to Perl. Basically it would just
be an additional copy of perl with one unresolved reference to a C subroutine
which would be called on any Perl subroutine that wasn't defined in the
script. That glue routine would be passed the name of the subroutine and
the Perl stack, and would then resolve the name of the subroutine to
some glorious switch-like structure that calls the C subroutine of your
choice, having transmogrified the arguments as necessary. Presumably the
glue routine could mostly be boilerplate, perhaps automatically generated
from a file describing the library or libraries to be accessed.
Can anyone see a better way to do this? A runtime fasl'er would be neat,
but rather less portable than this. And the single entry point to the
glue routine seems much more maintainable than trying to stitch various
libraries into Perl as built-in operators.
This is not just blue-sky speculation. I'm actually going to do this,
since it's needed to do efficient regression testing on certain libraries
here on my project. Your comments in the next day or two might influence
how this comes out.
I suspect the sql support mentioned earlier could be added this way. Or
any other database support that has a C library.
I suppose there might be some way of using this to support the dbm variants
too. Suppose we had a single altdbmopen that could bind an associative
array to subroutine names to implement fetch, store, etc. Then these
subroutines could be supplied by the glue routine. Or by the perl script
itself. Yowie! I wonder if there's a use for that?
Larry