On Tue, Aug 16, 2005 at 01:16:19PM -0700, Darren Duncan wrote: > At 4:04 PM +0100 8/16/05, Tim Bunce wrote: > >I was a little dissapointed that there wasn't greater focus on using > >Perl6 features - especially as it would have helped kick-start my own > >understanding of Perl6 topics that I expect to be significant (such as > >Roles and Pairs, to pick two at random). Perhaps the community of > >Perl6+DBI users is too small at this point. > > One way that the Perl 6 thought process can be started is in > considering the design principles laid out in Damian's new Best > Practices book. I said to Damian at OSCON that I thought the > practices he was putting forward were intended to get people thinking > now in Perl 5 about ways of doing things that will be the natural way > of doing them in Perl 6; he said something along the lines that I had > good insight. So these practices are probably some good things to > keep in mind as we move forward.
Yeap. I'm awaiting delivery of that one, plus several others including MJDs Higher Order Perl. > Now, speaking specifically in Perl 6 terms ... > > I suggest that DBI v2 has a more formal separation between interface > and implementation. The parts of DBI can be grouped into these > categories: > > 1. Role definitions for the public behaviour/API that DBI-using apps see. > 2. Role definitions for the behaviour/API that DBI drivers/engines must have. > 3. Class definitions that implement #1 and invoke #2. > 4. Class definitions having a generic implementation of #2 or parts > thereof, which a driver/engine can complete or override. > 5. Basic utility classes that exist to the side of the above, which > such as DBI drivers can optionally use to do some common things > without rolling their own. > 6. A basic test suite. I agree entirely - except for the word "basic" in item 6 :) One of the key things missing from DBI 1 was a test suite that could be reused to test/validate different drivers. Note that what you've described is essentially just what JDBC is. Only JDBC has a comprehensive driver test/validate suite. At the moment I'm thinking in terms of a Parrot-level DBDI modeled on JDBC, with a thin Perl6-specific DBI layered on top. Other languages targeting Parrot would have their own thin language adaption layers. > I also recommend expelling some parts of the DBI distro into their > own distros and/or leaving them to third parties. A prime example is > the proxy server/client stuff; that should be a separate project. I'd like to see someone do a stateless proxy sometime (as I've outlined previously) and I'll be ensuring there's a serializable RowSet object available - but, yes, such things should be separate. Tim.
