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.


Reply via email to