Re: Time to Document Callbacks

On Oct 28, 2009, at 2:59 AM, Tim Bunce wrote:

>> That looks nice. Are STHs the only things that are "children"?
>
> DBHs are children of DRHs (but I try to avoid talking about DRHs).

Yes, let's pretend they don't exist here.

> Here's a deal: you write some tests for ChildCallbacks in
> t/70callbacks.t and I'll implement them.

Deal.

>> Oh, nice. Does that mean you'll have more time for the DBI?
>
> That's the hope.

W00t.

>> Yeah, looks pretty nice. Would we also be able to pass them to  
>> prepare()?
>
> No. Much as I'd like to change prepare() to take method attributes  
> like
> connect I'm nervous of making that change. I'd happily support someone
> else doing the leg work though.

Out of my league.

>> I'm starting to fail to see the point of callbacks aside from  
>> connect().
>> :-(
>
> I'm probably being over-cautious. Most drivers use fetch() or
> fetchrow_arrayref() as the lowest-level calling method used by the  
> other
> fetch* ad select* methods. So applying the same callback to both would
> work find in most cases.

If I'm applying a callback to the "fetch" method, I expect it to  
execute when I actually call the fetch method on the STH to which I  
applied it. Reasonable, no? Is there some reason that wouldn't happen?  
If so, I'd call it a bug in the driver, frankly.

>> Hrm. That'd be inconsistent with the way precallbacks work.
>
> Yeah, well, it was just a guess off the top of my head :)
> I'd need to think about it and look at what could would be involved  
> and
> what would be effcient.

I was thinking it would get the same arguments as the precallback,  
with an additional one that's a reference to the return value(s).

Best,

David