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.

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 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.

-- Darren Duncan

Reply via email to