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.
