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.

Thank you for dropping it.

If you really want to avoid passing in the dbh all the time, you're crying out for an object. Your object would more or less just store the dbh (maybe there's other things, too, that make sense for your package, I don't know, I don't use Oracle). Then it would be called via $obj->my_function(123,456) as the $obj created would be, presumably, blessed into MyPackage. I'm sure someone here could help with the design in more detail.

If I were ever to use Oracle, and I happened upon your module, and you were asking people to use this style, I would have serious doubts as to the reliability of the module, and, if I were to use it anyway, I sure as heck would not be using this syntax. It really is, IMO, that bad.

Now, if someone were to use it in a complex, multi-package obfu, that would be different. "Can you trace this program without running it through the debugger or the deparser?" Here the goal is unreadable code. But my production code using your module ... that needs to be maintainable, and $dbh->Mypackage::my_function(123, 456) is not it.

(Of course, I'm also quite partial to object wrappers around the dbh object ... having put one of those on CPAN myself ;->)

While I agree that it should not be casually used, there are cases where I find this feature useful. And so I wouldn't categorically say that people shouldn't use it.

So I should stop using SUPER and should definitely avoid TheDamian's NEXT?

Of course not.

SUPER:: is part of perl's OO system, and a built in pseudo-package. So as far as I am concerned, it is a different story.

As for NEXT, thats up to you if you want to use it. No doubt that TheDamian knows what he is doing, but that's a pretty crazy module. Personally I just try to avoid designing anything which would need it in the first place.

However, what the OP was actually talking about was basically abusing a hole in perl's module/object system (at least thats what I see it as). The OP is actually talking about bascially using this to allow any random blessed object to become the first argument in a function, not a method. This is different from the controlled method dispatching of SUPER and NEXT.

-stvn

The OP was talking about exactly the trick that makes NEXT:: work. The fact that the result is a controlled method dispatch merely underscores that there is a legitimate reason to use this feature. True, SUPER:: is built-in and works differently, but there is no reason that it couldn't have been built using the same technique.

Personally I, like you, use SUPER:: and not NEXT::. But that's because I avoid multiple inheritance, and so have no reason to use NEXT::. If I used multiple inheritance, I would likely reverse and use NEXT:: instead of SUPER:: because SUPER:: does something that is fairly obviously the Wrong Thing to do.

I agree with you that there is a definite possibility of abuse in this feature. I'm even inclined to believe that most people who're using it are more likely to cause themselves grief than they are to benefit significantly. However many abusible features in Perl are also capable, when used in a disciplined way, of helping make code saner. For that reason I'm somewhat hesitant to say, "Never do this." I might be inclined to discourage people from using a feature. But I generally hesitate before saying never to do so.