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

I see nothing wrong with it as long as the names are appropriate in the context of the class. My work application has delete (for the SQL sense) and bless (for the Perl sense) supplied by the database abstraction, and other areas offer warn, die, open, close, log, format, umask, stat, send, ref and link.

And that's just the explicit ones: there are probably many more keywords used as fieldnames in the database which get autogenerated accessors of the same name.

The fact that they are also keywords has not caused any problems for me in the 4-5 years of using them, nor (to the best of my knowledge) for my colleague.

I don't use a syntax highlighter though. :)

Hugo

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

Replies are listed 'Best First'.
Re^2: Built-in Function Homonyms for Method Names Bad, Too? by jffry (Hermit) on Jan 26, 2006 at 00:13 UTC
Hmmm. That's a pretty convicing testimonial. At this point, I think I'll save myself the work of renaming the method in question, and see how it goes. From your experience, it looks like I'm pretty safe. Thanks, all, for the input so far!	[reply]
Re^3: Built-in Function Homonyms for Method Names Bad, Too? by davido (Cardinal) on Jan 26, 2006 at 00:33 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. 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	[reply] [d/l] [select]
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]


Clear questions and runnable code get the best and fastest answer
	PerlMonks