Aristotle raised an obvious point about my Sub::Signatures module.
Please just tell me it isn't based on source filtersââ¬Â¦ :-)
OK, it's not based on source filters.
Now that I have the lying out of the way, I can understand the hesitation about them. I worked for Rentrak for a year and they did something very similar (but on a much smaller scope) to what I'm trying to do, but they did it with Filter::Util::Call. Naturally, when I first started working with this I complained heartily to my programming friends about using a source filter in production code. And not just any old production code, either. We're talking about code that is rightfully called "enterprise class." And you know what? In the entire time I used it, I only stumbled across one bug (and admittedly it was a bugger to track down.) I know what the bug is and it's not going to be in my version :)
So after working with a source filter for over a year, what did I discover? Source filters, when done properly, can make programming much, much easier. I didn't realize how much I missed signatures until I had them again. I also didn't realize how much I missed having an entire class of bugs pretty much disappear because I had signatures. For the one bug that was caused by this source filter, programming was much more productive and bug free.
I was wrong about source filters. I used to think they were terribly evil and should not be used, but now I realize (as with all dogmatism) that this is not universally the case. Admittedly, source filters generally need to be some of the most heavily tested code, but the payoff can be huge.
But serious programmers don't use source filters, right? Don't tell that to Damian and Ingy, two well-known and respected programmers who are quite happy to reach for source filters when that's the solution to a thorny problem. Those, naturally, are two that come to mind but there are plenty of others. Source filters are to be used sparingly, but it's not the case that they should never be used. They are not evil, just dangerous.
Question: what's wrong with the following picture?
Source filters, when done properly, can make programming much, much easier. I didn't realize how much I missed signatures until I had them again.
Answer: these sentences have nothing to do with each other. Your argument is fallacious.
I did not condemn the idea of subroutine signatures at any point. I am deprecating source filters. I asked whether Sub::Signatures achieved the thing I want using the thing I don't, because I like Inline::Files and Switch too, but both of them known to be ill-suited for production use.
Incidentally, both of them are Damian modules. As far as Ingy's code is concerned, most of it gives me the shivers.
Re:
Ovid on 2004-12-06T04:39:14
The sentences appear to have nothing to do with each other because there's a chain of logic between the two that's not explicitly spelled out. 1. Subroutine signatures eliminate common problems in Perl. 2. Source filters can be used to implement subroutine signatures. 3. Therefore, source filters can be used to make programming easier (yes, there are still a few gaps, but without being too pedantic, you can see where I'm coming from.) As for whether or not this addresses your particular concern, that's something you'd have to decide for yourself.
As a more concrete example, you can read through one of my personal experiences with source filters. The gains far outweighed the losses. Seeing source filters actually work to my advantage is what changed my mind. Production on our code would have been slower without it.
Re:
Aristotle on 2004-12-06T06:37:49
Again: is there no other way by which subroutine signatures could be implemented than source filters?Re:
Ovid on 2004-12-06T06:44:15
The only way I can think of is to rewrite the guts of Perl. Of course, that project is already started and it's called Perl 6
:) I think you might be able to do something with attributes, but that wouldn't give you the dispatching that is the primary benefit of this module. Re:
Aristotle on 2004-12-06T14:37:27
Depends on the syntax — I cannot think of a way to implement yours without a filter either, but my thinking is more along the lines of not inventing new syntax at all, rather simply passing the function as a closure to some other function. Perl is introspective enough to do the backend stuff without source filtering.
Here's a suggestion that would reconcile both our views:
Make the main module filter-free, using some interface concoction like multisub( foo => '($bar, $baz)', sub { } ); (for demonstration purposes; I know this sucks), then put the filter in an add-on module that lets people write sub foo($bar, $baz) { } if that's what they want.
Why have it your way or my way when both are possible?
