On Oct 27, 2009, at 3:24 PM, Tim Bunce wrote:

>  The "simplest thing that could possibly work" is probably:
> 
>     $dbh->{Callbacks} = {
>         method_foo => sub { ... },
>         method_bar => sub { ... },
>         ChildCallbacks => {
>             method_foo => sub { ... },
>             method_bar => sub { ... },
>         }
>     }
> 
>  so the code that creates a child handle can just check for
>  ChildCallbacks on the parent handle and set those as the Callbacks for
>  the new handle.

That looks nice. Are STHs the only things that are "children"?

> > Yes, I saw that in our
> > [exchange](http://markmail.org/message/m2lr3n74nluh52jn) in 2005.  
> > What
> > would it take to make this happen?
> 
>  Let's get Callbacks and ChildCallbacks documented first.

Okay. Maybe it'll be done when I wake up in the morning? ;-P

> > Oh, that kind of callback. I'd love to see attributes to prepare  
> > passed on
> > to the sth. It makes perfect sense to me. I note that you thought  
> > in 2005
> > that it wouldn't happen before DBI2, but since that's probably  
> > another 5
> > years away at this rate…
> 
>  [Tangental observation: NYTProf v3 is nearly done... :-]

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

>  ChildCallbacks seems like the way to go. Simple, effective, and easy  
>  to
>  implement.

Yeah, looks pretty nice. Would we also be able to pass them to prepare 
()?

>  Yes, it's one of the two fundamental problems with the Callback  
>  approach.
>  The other being that multiple callbacks for the same method can't
>  co-exist on the same handle.  Both need to be documented.

Right. The driver-specific issue is troubling, frankly.

> > Well, and tie is pretty hackish IMHO.
> 
>  The implementation (and performance) may not be great, but the concept
>  of tie (values vs containers) is good. Overloading would also work.
>  Either way it should be wrapped up in a nice interface.

Such as?

> > But let me cite another example. In our prior discussions, you
> > [wrote](http://markmail.org/message/dgnpmnzkk4g532lc):
> >
> >> Note that sth callbacks, for example, give you a relatively clean  
> >> way to
> >> set the UTF8 flag on fetched data.
> 
>  It seemed like a good idea at the time but I recant that now.
>  It's workable only for someone who knows what driver and methods  
>  will be
>  used to fetch data from a given handle. So it's just about okay for
>  in-house use but I couldn't recommend it as a general solution.

I'm starting to fail to see the point of callbacks aside from connect 
(). :-(

>  It would need post-call callbacks. How they get called would depend on
>  what works most efficiently and reasonably elegantly. I'd guess that  
>  the
>  values being returned would be in @_ (as aliases) and $_ would contain
>  the handle.

Hrm. That'd be inconsistent with the way precallbacks work.

>  Lots of people have published DBIx::* modules and I'd guess many could
>  think of interesting uses for Callbacks. End users couldn't use more
>  than one such module at a time if they want to add callbacks on the  
>  same
>  methods.

Fair point.

>  On the other hand I'm happy to await the cowpaths.

Yeah, I think it's useful to wait to see what the demand looks like.

>  My suggestion (in http://markmail.org/message/dgnpmnzkk4g532lc) in  
>  2005
>  still seems reaonable:
> 
>  $h->callback_add( $method_name, $code_ref [, $pre_or_post ]);
>  $h->callback_delete( $method_name, $code_ref [, $pre_or_post ]);

I'd rather they were add_callback and delete_callback (or  
del_callback). But the method name isn't that important, and the API  
looks okay to me.

>  except that $h->{Callbacks} = { name => $code, ... } is great for
>  setting up multiple callbacks in one go. So perhaps we'd have:
> 
>  $h->add_callbacks( { name => $code, ... } );
> 
>  and make $h->{Callbacks} = ... automatically fire the add_callbacks
>  method.

Even better.

>  We'd still need a way to express pre-vs-post-call, so perhaps
>  allow
> 
>  $h->add_callbacks( { name => [ $pre_code, $post_code ], ... } );
> 
>  In which case we've ended up back at the current (proposed) data
>  structure but with a method to provide some abstraction.
>  In which case adding the method can wait until we need to support
>  multiple callbacks :)

Works for me.

Best,

David