in reply to RFC: Business::CreditCard::Obscure

I'm certainly in favor of code reuse and OO and input validation, but the actual functionality here is so small that it hardly seems worth it. I do this in my own code with this sub: 
sub _safe_card_number {
    my ($class, $card_number) = @_;
    $card_number =
      'X' x (length($card_number) - 4) . substr($card_number, -4);
    return $card_number;
}

[download]
I could imagine someone wanting to change the 'X' to something else, but leaving the last 4 characters is pretty much universal from what I've seen.

Replies are listed 'Best First'.
Re^2: RFC: Business::CreditCard::Obscure
by radiantmatrix (Parson) on Aug 25, 2006 at 14:32 UTC

    You're using substr repetitively, but you don't need to. 

    print obscure('5555666677778888', 4, 2, '*');

sub obscure {
   my ($num, $tip, $tail, $char) = @_;
   my $repl_length = length($num) - $tip - $tail;

   substr($num, $tip, $repl_length) = $char x $repl_length;
   
   return $num;
}

__END__
5555**********88

    [download]

    Looking at this again, I'm noting that this in production code should really make use of some data validation. Calling obscure() with a negative value for $tip would have some interesting results, for example. ;-)

    Updates:

    • 2006-08-25 : Added thoughts about data validation

    <–radiant.matrix–>
    A collection of thoughts and links from the minds of geeks
    The Code that can be seen is not the true Code
    I haven't found a problem yet that can't be solved by a well-placed trebuchet
[reply]
[d/l]
[select]
      I know, I just don't like lvalue subtring. It might be faster, for people who aren't bothered by the way it looks.
[reply]

In Section Meditations