"Tim Bunce" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> On Tue, May 17, 2005 at 04:17:15PM -0700, Jonathan Leffler wrote:
>
> > Also, the example code used $dbh->can()
> > as if it returns some sort of subroutine reference - whereas the
> > manual only says it returns true or false. Is the DBI manual
> > inaccurate or just incomplete and it actually returns something
> > usable?
>
> There's fairly deep magic going on here. Returning a code-ref is
> undocumented because of potential problems. And guess what...
> here's a problem.
Well, it seems to me that if there are some potential problems,
it should be documented that usage of can()'s return value as a subref
(as some people got used) is a bad practice.
In any case, such a limitation breaks standard behaviour, implemented in
the 'UNIVERSAL' module.
> sub prepare_sql
> {
> # uncommenting the next line will avoid core dump
> # return $DBH->prepare( 'select * from ');
> my $sub = $DBH->can( 'prepare');
> @_ = ( $DBH, 'select * from ' );
> goto &$sub;
> }
>
> Messing with @_ before using goto & is just asking for trouble.
Hmm ... Is it a peculiarity of DBI, or DBD::Informix?
I made up another test case, without DBI and DBD::Informix.
It obtains a subroutine reference by calling a blessed reference's 'can()'
method,
plays with @_ and calls the subroutine via 'goto &$sub'.
After that things go the same way: dying, catching, etc.
But no cores, no SIGBUS'es ...
Anyway, it seems to me that any experiments with pure perl code
shoud not bring perl's internal data structures to an inconsistent
state, as we see in this example.
Am not i right?
>
> Bottom line: If it hurts then stop doing it.
That's the easiest way for me. I already have a workaround which solves
the problem, at least for this very code. I just call the subroutine
reference
as $sub->(@params);
Hope, this won't bring me problems in future.
Best regards,
Konstantin Solodovnikov,
JSC "Web Media Servises".
[EMAIL PROTECTED]
