Re: How to complain about changes to a module? (And what good would it do?)

[Corion]

There once were complaints about how base.pm had accrued bloat and feature creep, and the only way that was seen by p5p was to let it rot as the dead carcass it is and to elect a slimmer, fitter substitute into the core. The better solution would've been to cut away the cancer but neither the author nor p5p followed through on that.

So my view on such situations isn't all positive, even though I got a talk out of it and a module into the core that way. Possibly, if you were to name names, it could frustrate the unnamed frameworking author so that you get assigned maintainership. This would be the most positive alternative I see. Actually, while we're dreaming crack pipe dreams, maybe you can enter a fruitful discussion with the author (note: avoid terms like "ruined", "unnecessary") and either you realize that the author was right all the time or the author realizes that his extensions should go into a subclass.

So, I see little gain in complaining. You can always fork the module in question.

[BrowserUk]

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.

[Corion]

You overestimate my global awareness, but if a subclass, either by you or the author is possible, that sounds like a good way. I had a remotely similar situation with Schedule::Cron::Nofork, where I replaced some functionality with mine, but I think I didn't ever contact the author about changing Schedule::Cron. Eventually, S:C acquired the functionality itself and I should retire my module some day.

[BrowserUk]

but if a subclass, either by you

The problem is the maintainers changes should be a subclass of the original module (or a completely different module). And you cannot de-subclass a class. That is, I cannot produce a module that is a subclass of the modified module that removes the added functionality and overhead.

So the only option for me is to re-release the original code under a new name. Which, besides any other problems with picking a namespace is a pain because the original name and functionality where perfectly matched.