I personally see it as a source of ambiguity and difficult to predict bugs. What if you define return() within a package, to be used as an object method, but then within the class itself one of the subs uses return()? Which return() will be called, the package one, or the core one? I had to test to find out (in my simple test, the core routine got called). I see it as an unnecessary source of potential mistakes.
Perhaps a :method attribute would help. To quote from the docs:
method Indicates that the referenced subroutine is a method. This has a meaning when taken together with the locked attribute, as describe +d there. It also means that a subroutine so marked will not trigger the "Ambiguous call resolved as CORE::%s" warning.
In reply to Re^4: Built-in Function Homonyms for Method Names Bad, Too?
by blazar
in thread Built-in Function Homonyms for Method Names Bad, Too?
by jffry
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |