You could make that argument, but it fails when you need to use those builtins inside the package that defines those methods. And, just because Unix is vowel-deficient doesn't mean that you need to be. :)

Well - that depends on how you call them. As long as you carry on calling them as methods you'll be just fine - inside the declaring package or not.

Personally I'm anti using keywords in procedural/functional APIs for exactly the reason you put forward. For OO interfaces I think it's fine - as long as the functionality matches the keywords they're copying. pos works well for me in this instance.

What happens when you want to use the real pos()? I'm not worried about the methods. I'm talking about using the builtins, which you don't call as methods. :)

Update: You have to be able to explain to everyone else who looks at your code why Perl ignores the subroutine you defined, which one you really wanted, and all sorts of other things. pos() may not be the best example though.

#!/usr/bin/perl
use warnings;

sub shift { }

my @array = qw( 1 2 3 );

shift @array;
[download]

In general, don't purposedly cause ambiguity.

--
brian d foy <brian@stonehenge.com>
Subscribe to The Perl Review

What happens when you want to use the real pos()? I'm not worried about the methods. I'm talking about using the builtins, which you don't call as methods. :)

?

use strict;
use warnings;

{   package Foo;
    
    sub pos { "pos" }
    
    sub bar {
        my $foo = "xxx";
        $foo =~ m/x/g;
        return pos $foo;
    };
    
};

use Test::More 'no_plan';
is( Foo->pos, "pos",    "we can call Foo's pos method"  );
is( Foo->bar, 1,        "and still use pos inside the package" );
[download]