Do you know where your variables are? | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
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:
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.
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).
I'll probably drop the idea because the syntax is too confusing. In reply to Re^2: $object->UnrelatedPackage::some_subroutine()
by Thilosophy
|
|