On 8/16/05, Tim Bunce <[EMAIL PROTECTED]> 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.
I'm afraid that DBI2 for Perl 6 will fall into the trap that I sometimes feel like DBI1 fell into: the curse of being designed before the idioms and Best Practices of API design in the language have been established. I think it'll take years, and much actual production experience building Perl 6 modules before the community learns what works and what doesn't for a Perl 6 API (let alone implementation). So trying to pin down a "properly Perl-6-ish" API before Perl 6 is even through the language design process strikes me as a Very Bad Idea. That could explain why there were so few Perl 6 related suggestions: no one knows how to design a good Perl 6 API yet, and any guess is very likely to be wrong. Instead, suggestions have focused on what we do know: DBI in Perl 5 and Perl 5 API design. In that spirit, here's my suggestion: no more configuration through magic/tied hashes. (e.g., $dbh->{'AutoCommit'} = 1) (Probably goes without saying, but I wanted to make sure someone said it ;) Anyway, it maybe worthwhile to have a DBI 1.99 first, and then maybe a 1.999 after that. Basically, get one or two willing DBD authors who will help you to test and then throw away the first two attempts at a Perl 6 DBI API. Then at least you'll have some confidence when you commit to a DBI 2.0 API...which will be several years after Perl 6 is released, I hope. Of course, *someone* has to "go first" so we can all learn what works best in Perl 6. I'm just saying that maybe DBI, which took the bullet in Perl 5 to some degree, is under no obligation to do so again. (This assumes that we'll have some way to use Perl 5 DBI within Perl 6 to tide us over, of course...) -John