SPUG: Runtime binding, drivers

Trevor Leffler tleffler at u.washington.edu
Tue Oct 8 19:26:08 CDT 2002

Hi all,

I've been researching the implementation of "drivers" in Perl, and am looking 
for some feedback from somebody, anybody.  My motivation is from working with a 
FileSystem object that lets me do basic file manipulation on a filesystem (list, 
put, move, copy, delete, etc.).  There are however, several kinds of filesystems 
that I might want to have an implementation for: local, remote (afs, nfs, 
samba...), virtual, etc.

So a couple things come to mind: DBI, and Java's interface/implementation class 
support.  DBI does all kinds of magic: outer and inner objects via tie, XS code, 
lots of sub-classing and run-time loading and binding of classes.  I don't claim 
to understand all that goes on under the hood, but the framework is interesting 
and I wonder about its potential use as a generic object/driver mechanism for 
all sorts of other objects.  I also wonder what kinds of beneficial features it 
provides to driver implementers.

Java's support appears more straightforward, and is easily replicated in Perl. 
Once class is the interface, which itemizes method signatures, creates 
constants, and provides documentation.  It's small, contains no real code, and 
is easy to pass around to implementation developers.  A second class actually 
implements the interface.  The compiler enforces the contract, and the developer 
just hacks out the necessary code.  (Interfaces are also Java's tool for 
multiple inheritance and call-backs.)

Perl can do all that.  Well, it doesn't natively enforce API contracts, but 
that's part of its flexibility--we *could* enforce them if we wanted to.  In 
addition to my wondering about DBI (above), I am curious about your thoughts and 
experiences related to the "one interface (DBI), many implementations (DBD::*)" 
concept, specifically relating to Perl.  Are there any best practices?  Any 
existing modules that lend themselves to this?  Is this an attempt to make Perl 
look like other languages, or does this architecture have benefits (I think it 
does)?  Are there other ways to think about this problem?

I look forward to your comments.

Trevor Leffler, Software Developer
PETTT / Ed-Tech Development Group
Educational Partnerships & Learning Technologies
University of Washington
(206) 616-3406 / OUGL 230, Box 353080

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
     Seattle Perl Users Group (SPUG) Home Page: http://seattleperl.org

More information about the spug-list mailing list