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

There's one gotcha that others haven't mentioned, which is an issue for you, the module author, rather than for those using your module.

The gotcha is that any attempts to use the builtins inside your module: return, split, delete, will result in calls to the subs in your package, not the builtins (and they will probably fall over as they are expecting an object as $_[0]). To get the real builtins, they now need to be qualified, viz: CORE::return, CORE::split and CORE::delete.

Care is needed coding your module, as this is a source of bugs.

--

Oh Lord, won’t you burn me a Knoppix CD ?
My friends all rate Windows, I must disagree.
Your powers of persuasion will set them all free,
So oh Lord, won’t you burn me a Knoppix CD ?
(Missquoting Janis Joplin)

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

Replies are listed 'Best First'.
Re^2: Built-in Function Homonyms for Method Names Bad, Too? by hv (Prior) on Jan 27, 2006 at 00:16 UTC
The gotcha is that any attempts to use the builtins inside your module: return, split, delete, will result in calls to the subs in your package, not the builtins [...] I can't find a test case for this behaviour - do you have an example? There is a distinction between strong and weak keywords ¹ which shows a slight difference in behaviour. With a strong keyword, the keyword overrides the subroutine: `zen% perl -wle 'my %hash; sub delete { die "not this one" } delete($ +hash{key})' zen%` [download] A weak keyword gives a warning, but is still preferred to the subroutine: `zen% perl -wle 'sub bless { die "not this one" } my $a=bless({});' Ambiguous call resolved as CORE::bless(), qualify as such or use & a +t -e line 1. zen%` [download] I'm sure I'm missing something that would justify your comment, but I can't offhand think what it is. Hugo ¹ The distinction between weak and strong keywords is probably not well documented; in older perls I think the only way to check was to examine the C code in toke.c, but happily perl-5.8.7 now bundle a script `perl_keyword.pl` to generate the code, which has clear lists of weak (`@neg`) and strong (`@pos`) keywords at the start of the script.	[reply] [d/l] [select]
Re^2: Built-in Function Homonyms for Method Names Bad, Too? by jffry (Hermit) on Jan 26, 2006 at 17:26 UTC
Zoiks, Scooby! That scared me right back into avoiding homonym method names. At this point I've flip-flopped back, and I think I'll stay here on this side of caution. I'm changing 'em now while I'm still early in this project. Thanks, all, even to those who told me to leave 'em as-is, but my paranoia probably would have given me too much tension anyway.	[reply]
Re^3: Built-in Function Homonyms for Method Names Bad, Too? by macrobat (Beadle) on Jan 26, 2006 at 18:54 UTC
Remember, though, that polymorphism is one of the selling buzzwords of object-oriented programming: you can use the same method name on objects of a different class, and have it do different things. That's desired. (And yes, I know that "objects of a different class" and "builtins" don't equate, but in this case they overlap enough for the benefit to still hold.) Also, although this means you need to be a little more cautious in your module, remember that the whole point of creating a module is so that it will get re-used. A little burden up-front is (presumably) worth it in the long run. If a dupe of a built-in name makes the most sense to you, it will probably be easy to remember (and therefore easy to use) for your clients as well.	[reply]