|No such thing as a small change|
and either you realize that the author was right all the time or the author realizes that his extensions should go into a subclass.
I suspect that you are aware of more than is in the OP. You've hit the nail exactly on the head with your "should be a subclass" comment.
So, I see little gain in complaining. You can always fork the module in question.
The purpose of a complaint (as opposed to moaning) is to try and change things. But it's kind of hard being as the maintainer has cut himself off from the (this) community.
At the basic level, forking the module in question is trivial, the original is a 30 line pure perl module. The problems start with choosing a new namespace.
At the deeper level, to do the job right would require forking a couple of other distinctly non-trivial, XS modules with huge platform dependancies which I would have no way of testing never mind supporting. Also, I find getting XS code correct to be closely akin to black magic. A set of barely documented incantations that when they work, you're never quite sure why they do, and when they don't they are all but impossible to debug. Trying to corrolate disassembled assembler or C back to XS is nigh impossible. And getting help even harder.
If you can find an existing module that does something similar, and stick to existing patterns of code, you can sometime get stuff to work. But if you look at the time it took for the experts to work out all the bugs and caveats in List::Util::reduce() you can see that it's not just me that has the problems.
Thanks to everyone who gave this serious consideration and posted. I now know what I've got to do, I just need to work out whether I am up to the challenge.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.