Interesting yes, but IMO an all around bad idea. Not only does it cause confusion as to what $dbh is, it also causes confusion as how the SomeDatabaseStuff package fits into everything. As far as I am concerned, this is basically only useful as an obfuscation technique, and should never be used in real code.

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);
[download]

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);
[download]

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');
[download]

I'll probably drop the idea because the syntax is too confusing.