Hmm. I was going to mention this pattern in the next version of DBIx::ProcedureCall. That module gives you auto-generated wrapper subroutines for database stored procedures. It does not use object orientation, just creates plain old functions. All these functions take a DBI handle as their first parameter:
# create wrapper subroutines for the Oracle # PL/SQL package MyPackage use DBIx::ProcedureCall qw ( MyPackage:package ); # call a function in that package # (passing in the DBI handle to use) my $result = MyPackage::my_function( $dbh, 123, 456);
I am unhappy with having to pass in $dbh every time. In my own use of the module I have some custom code to obtain the handle automatically, but this is application-specific and cannot be included in the module (although the module could be refactored a little to allow everyone to extend it in this fashion).
So I was thinking to use the strange syntax we are currently discussing to at least visually separate $dbh from the "real" parameters (that get passed to the subroutine). This probably also helps as a reminder not to forget that first parameter.
my $result = $dbh->MyPackage::my_function( 123, 456);
Of course, this looks like a method call on $dbh, which it is not. There is really no OO going on here, although it does look like it.
On the other hand, OO considerations aside, I liked the way how this makes calling a stored procedure look similar to doing a select statement (or other DBI operations).
my $result = $dbh->selectrow_arrayref('select * from blah');
I'll probably drop the idea because the syntax is too confusing.
In reply to Re^2: $object->UnrelatedPackage::some_subroutine()
by Thilosophy
in thread $object->UnrelatedPackage::some_subroutine()
by Thilosophy
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |