Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!jpl-devvax!lwall From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) Newsgroups: comp.lang.perl Subject: Opening new cans of worms Keywords: perl, dbz, dbm Message-ID: <8039@jpl-devvax.JPL.NASA.GOV> Date: 9 May 90 17:16:14 GMT References: <90May7.143910edt.19586@me.utoronto.ca> Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) Organization: Jet Propulsion Laboratory, Pasadena, CA Lines: 50 In article 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