Re^3: Built-in Function Homonyms for Method Names Bad, Too?

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.

Can you be sure that at some point down the road one of those overloaded names won't be invoked with the expectation of getting one behavior but with the result of getting the other behavior? I know there are hard and fast rules governing such things, but it's easier to just avoid the issue in the first place.

Dave

Comment on Re^3: Built-in Function Homonyms for Method Names Bad, Too? Select or Download Code

Replies are listed 'Best First'.
Re^4: Built-in Function Homonyms for Method Names Bad, Too? by blazar (Canon) on Apr 19, 2007 at 10:05 UTC
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.` [download]	[reply] [d/l] [select]
Re^4: Built-in Function Homonyms for Method Names Bad, Too? by jffry (Hermit) on Jan 26, 2006 at 18:49 UTC
Agreed & done. Now, if Perl 6 will leave the word 'remove' alone...	[reply]