Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

CPAN Author Struggle: Am I a jerk? (unter-jerk)

by cmv (Chaplain)
on Sep 20, 2007 at 14:43 UTC ( [id://640142]=perlmeditation: print w/replies, xml ) Need Help??


I've been discussing a bug report that I submitted for Business::CreditCard, with Ivan Kohler (the author) for over a year now.

In his last correspondence, he suggested that I "have an impartial friend re-read the correspondence with you and see if they can't help you understand.".

Taking this advice to heart, I'm asking any perlmonks here if they could help me out. I clearly don't understand the technical reason Ivan has, that makes him so reluctant to make my suggested change. I also thought he was provoked/offended, when he wasn't. Am I being a jerk?



UPDATE: It seems that if I'm not actually being a jerk, I'm getting very close.

Thanks all around to everyone who responded, even tye who felt I actually was a jerk (although a real jerk would have given his module low ratings as part of the sour-grapes review :-). Thank you all for your candor and helping me see things from a module-author's point of view (of which I am not). I value ALL this feedback.

  • Comment on CPAN Author Struggle: Am I a jerk? (unter-jerk)

Replies are listed 'Best First'.
Re: CPAN Author Struggle: Am I a jerk?
by jdporter (Paladin) on Sep 20, 2007 at 15:20 UTC

    Based on the posted email exchange, I wouldn't say either one of you is being a jerk... but you're in danger of being a jerk if you continue to insist that Ivan change his module as you desire.
    Ivan wrote:

    This module is for verifying _real world_ *credit cards*. It is *NOT* a pedantic implementation of the ISO 7812 standard, a general-purpose LUHN implementation, or intended for use with "creditcard-like account numbers".
    That's it. Let it go.

    A word spoken in Mind will reach its own level, in the objective world, by its own weight
Re: CPAN Author Struggle: Am I a jerk?
by duff (Parson) on Sep 20, 2007 at 15:38 UTC

    Okay Craig, let's look at it from the flip side. Say he implements your requested change. There may be people out there who are using this module on real, actual credit card numbers which are always at least 13 digits. Now, are you going to deal with all of the bug reports about how upgrading to the latest version of Business::CreditCard broke some applications because it suddenly started accepting 10 digit numbers when before it did not?

    Ivan's approach is conservative and correct.

    As an alternative suggestion maybe you can convince Ivan to add a verifyISO() routine that acts as you desire. (No one is likely to be depending on something that doesn't exist :-) But if he doesn't want to do that, you still have other options--"subclass" his module (I don't know if it's OO or not but a similar idea holds even if it's not), create your own module, use his module, but write your own routine that you inject into his namespace for your own nefarious purposes, etc. :)

Re: CPAN Author Struggle: Am I a jerk?
by ikegami (Patriarch) on Sep 20, 2007 at 15:35 UTC

    Your original beef was that you couldn't use Business::CreditCard for Authen::PIN. You accepted that "Authn::PIN probably shouldn't use this module for a general-purpose LUHN implementation."

    But then it became a question of whether validate should obey ISO-7812 or follow real-world practices. Do you even have any stake is this? I mean, do you even use the module? It sounds to me you like you found a "problem" in a module you don't even use. I suspect the validate is almost exclusively used to verify a credit card number before initiating a transaction. Anyone using it for that purpose would welcome the cut in false-positives that checking for a minimum length of 13 digits provides.

    If you do use this module, and this check is causing a problem, you should be discussing that problem. If problems or false-negatives occur, the author is willing to re-open the issue: "Feel free to re-open this bug if verify() doesn't work with any real-world credit card number."

Re: CPAN Author Struggle: Am I a jerk?
by erroneousBollock (Curate) on Sep 20, 2007 at 15:11 UTC
    The reason doesn't seem to be technical. Ivan seems to have chosen a particular goal for the his module: validation of real world credit cards.

    He doesn't seem to believe that your argument (nor patch) add anything toward those goals. He's quite correct to insist that you fork the module should your goals differ.


Re: CPAN Author Struggle: Am I a jerk?
by tirwhan (Abbot) on Sep 20, 2007 at 15:12 UTC

    After reading through your email exchange my opinion would be that no, you're not being a jerk. OTOH I fully understand and agree with Ivans decision to verify credit card numbers by checking for a minimum length of 13 characters until there is a real-world case of a valid cc number with less than 13 characters. So if you need a module with your desired behaviour (and it is worth the effort to follow the updates of an upstream module over the years), you probably should fork and create a new module under a different name. Whether that module would be useful enough to upload to CPAN is for you to decide.

    All dogma is stupid.
Re: CPAN Author Struggle: Am I a jerk?
by eric256 (Parson) on Sep 20, 2007 at 16:25 UTC

    The only part that confused me was

    Feel free to re-open this bug if verify() doesn't work with any real-world credit card number or you have a patch. :)

    He asked for a patch then rejected it. Either way let it go and figure out a more appropriate module for your need. Lots of modules can be reused for unintended reasons but once its apparent he only wants to handle real cards let it be. Makeing a module better and work right is different from making it work more like you want ;) BTW the following code does what you want and still uses the module so you get any future enhancements. Definitely redundant code in that module for getting the check digit.

    sub check_last { my $last_digit = substr($_[0],-1); my $card = substr($_[0],0,-1); return 0+($last_digit == generate_last_digit($card)); }

    Eric Hodges
Re: CPAN Author Struggle: Am I a jerk? (unter-jerk)
by talexb (Chancellor) on Sep 21, 2007 at 01:15 UTC

    Interesting post. This is timely for me, since I coded up some additional stuff for WWW::Mechanize (to handle link titles) that I needed for some testing I'm doing. I got onto #perl to ask about the protocol for doing such a thing, and was told to submit a change to RT on CPAN, along with my justification.

    I have no idea what the author's reaction is going to be, but I've talked to Andy (once -- it's unlikely he'll remember), and I found him to be a great guy. He's also got his own opinions, and may decide, for a variety of different reasons not to include my changes. Hey, that's the way it goes. There are plenty of workarounds I can use if I want to continue to use my change in the future. It's not the end of the world if my change is rejected.

    Always remember, There's More Than One Way To Do It -- when you realize that you're trying to force something to happen in a certain way, maybe that's a sign you should be trying a different approach.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

      Create a patch set and backward compatability are the two major things I would advise.

      If your version is radically different from the current version of the module the likely hood of getting a feature included is minimal. If the current fuctionality is just plain wrong thats a bug and can be explained as such.

      If you need behavior that is different from the current module then provide a way of switching it on and off. The default should be off for compatibility but with time this may change.

      Provide a patch set against a specified version of the module. This allows the maintainer to easily evaluate what you have done and how it effects everything else. Including it in a open location, developer mailing list etc will allow other people to evaluate your changes and make suggestions even if the change isn't accepted.

      Take the GP example. This was just a straight bug report not a bug fix. These will often get rejected as being irritations unless they are genuine issues in the majority case.

      My personal opinion is the likely hood of the request being dealt with would have been better if a patch like the below snipet had been included.

      Hope it help


      On a train in the middle of nowhere

      sub validate { - my ($number) = @_; + my ($number, $param) = @_; my ($i, $sum, $weight); return 0 if $number =~ /[^\d\s]/; $number =~ s/\D//g; return 0 unless length($number) >= 9 && 0+$number; + return 0 unless length($number) >= 13 && !(defined $par am->{ISOs +trict} && $param->{ISOstrict}); for ($i = 0; $i < length($number) - 1; $i++) { $weight = substr($number, -1 * ($i + 2), 1) * (2 - ($i % 2)); $sum += (($weight < 10) ? $weight : ($weight - 9)); } return 1 if substr($number, -1) == (10 - $sum % 10) % 10; return 0; }

      Note: code unchecked

Re: CPAN Author Struggle: Am I a jerk?
by swampyankee (Parson) on Sep 20, 2007 at 20:48 UTC

    I suspect that "impartial friend" is an oxymoron, except in the limited case of the friend being a friend to Ivan Kohler and you.

    I've read the dialogue, and I think Ivan is right. I think he's right, with this as the this main groundmostly for this reason: any change in behavior visible to the user is a bad thing, unless there are cases where the module is behaving in contradiction to its documentation1. ISO 7812 may allow credit card numbers shorter or longer than 13 digits, but I suspect that shorter numbers are very unlikely, as 13 digits only allows five digits for the customer number.


    No, I don't think either Craig or Ivan are being "jerks." Disagreements don't imply either party is a jerk; it's the behavior during and after a disagreement that puts one (or both) participants into the state of jerk-dom. Both have legitimate reasons for their positions. Both are remaining civil, so neither is a jerk.

    I've got to stop writing these when I have to leave the keyboard.

    1 If the documentation says something other than 13 digit card numbers will work, and they don't, it's a bug, and Ivan should fix it. Apparently, it doesn't, so Craig was asking for an extension, which Ivan seems to consider as too likely to break existing applications.

    Editorial changes


    Information about American English usage here and here.

    Any Northeastern US area jobs? I'm currently unemployed.

Re: CPAN Author Struggle: Am I a jerk?
by oha (Friar) on Sep 20, 2007 at 15:12 UTC
    seems to me that you expect that the method verify() will only check the last digit, but the author expect a more usefull check for "real life".

    Note: having $code, you can chop it and generate the last digit, then compare with the chopped one.


    Update: i do not agree to suggest to fork the module, probably you can ask the author to make a verify_last_digit() method which does not check the length?

Re: CPAN Author Struggle: Am I a jerk? (yes)
by tye (Sage) on Sep 20, 2007 at 16:16 UTC

    You want to use verify() to check PINs from some other module so you pretend that you care about some ISO spec and then post a sour-grapes review based on this pretend concern of yours without mentioning your true motives. Yes, that was the action of a jerk.

    - tye        

Re: CPAN Author Struggle: Am I a jerk? (unter-jerk)
by goibhniu (Hermit) on Sep 21, 2007 at 14:32 UTC

    ++ for being brave enough to ask for honest feedback. I agree with several posters above. Not a jerk yet, but time to let go.

    I humbly seek wisdom.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://640142]
Approved by tirwhan
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others surveying the Monastery: (7)
As of 2024-05-28 08:26 GMT
Find Nodes?
    Voting Booth?

    No recent polls found