Re^6: RFC: Integer::Partition::Unrestricted

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]

Comment on Re^6: RFC: Integer::Partition::Unrestricted Download Code

Replies are listed 'Best First'.
Re^7: RFC: Integer::Partition::Unrestricted by Aristotle (Chancellor) on Mar 01, 2006 at 15:19 UTC
That’s exactly the point: there’s a call to `pos`, but it invokes pos, not your `sub pos`. That call to `pos` is ambiguous to the reader. I agree with brian on this one. Makeshifts last the longest.	[reply]
Re^8: RFC: Integer::Partition::Unrestricted by adrianh (Chancellor) on Mar 02, 2006 at 16:31 UTC
That’s exactly the point: there’s a call to pos, but it invokes pos, not your sub pos. That call to pos is ambiguous to the reader. That argument I can accept (if not agree with), but I didn't get that from the post before the update :-) Personally I don't find it an ambiguous read. I'm pretty religious about not using () for keywords, and not using prototypes for functions so the fact that it's `pos $foo` rather than `pos( $foo )` is already telling me that it's a keyword not a subroutine call. Combine that with knowing how perl treats clashes between subroutines and keywords and I know that it's not going to cause problems. However I can see that it's an issue that reasonable people can differ over.	[reply] [d/l] [select]