Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

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

by BrowserUk (Pope)
on Aug 29, 2008 at 03:19 UTC ( #707654=note: print w/replies, xml ) Need Help??


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

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.
  • Comment on Re^2: How to complain about changes to a module? (And what good would it do?)
  • Download Code

Replies are listed 'Best First'.
Re^3: How to complain about changes to a module? (And what good would it do?)
by Corion (Pope) on Aug 29, 2008 at 05:58 UTC

    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.

      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.


      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.

        But if you can make the case for a subclass and can demonstrate how the subclass would work for the original creator and your current code would still work with the base class, that's a far better position for entering the dialogue than having to say "Your changes suck, back them out." :)

        XXX::Lite?

        Or XXX::Simple? CGI::Simple has reduced functionality of the parent, sans HTML output, amoung other things. And, I believe, it's not built on top of the parent either but a complete rewrite. So in this context, "subclass" is quite a broad definition.

        I use a couple of old versions of modules (DBM::Deep, CGI::Session) because "recent" versions include XS dependancies which aren't currently available (negotiations with webhosters pending). Far from ideal; better would be Lite or Simple versions that were maintained.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://707654]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (2)
As of 2021-03-04 02:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My favorite kind of desktop background is:











    Results (98 votes). Check out past polls.

    Notices?