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