On Tue, Aug 16, 2005 at 03:58:54PM -0400, John Siracusa wrote: > 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.
I remember the early years of Perl 5 development, when a new feature was added there'd be a period of over-zealous use followed by a hangover as all the problems and edge-cases became apparent. With Perl 6 there's going to be some almighty hangovers :) > 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 ;) Hey, it seemed like a good idea at the time :) (Actually it's still a good idea in many ways, especially in relation to its behaviour for unknown driver-private attributes and DBI version skew. But it does need rethinking for DBI2.) > 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. It'll be DBI 2 as DBI 1 still has a very long life ahead of it, but it'll be DBI 2.0.00xxx for quite a while :) > 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...) I'm in no great rush as one of my core assumptions is that DBI v1 will be available in Perl 6 via either Ponie or direct embedding of libperl5.so. Tim.