SPUG: Runtime binding, drivers
tleffler at u.washington.edu
Tue Oct 8 19:26:08 CDT 2002
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