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

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!

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

$self -> split();
[download]

I don't think it's a bad practice. You should name your methods such that they make sense in light of the problem your trying to solve and how you will use your object regardless of whether or not those names happen to conincide with perl built-ins.

Well, there are plenty of decent synonyms I could use for method names instead. So that point is covered in my case.

I guess the tough question is: if I keep using these homonym method names is there some Perl syntax parsing nightmare I'm going to hit at some point.

OR

If you (plural) can't cite specific examples of Perl parsing dangers, is the threat of such dangers enough for me to not use homonyms.

I guess the tough question is: if I keep using these homonym method names is there some Perl syntax parsing nightmare I'm going to hit at some point.

Short answer is, if you're always calling methods with ->, then there won't be a problem. Parsing problems only come about when your in a place where a built in can live, and after -> isn't one of those places.

Personally I'm for using homonym method names when they make sense, since if they're used appropriately you already "know" what they do.

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.

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.

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.

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.

An update on this debate.

I have decided to avoid homonym method names. Well, I just spent 2 hours trying to figure out a bug that was caused by almost exactly this problem. I am using Object::InsideOut, and I was writing a module/Class for locking. So, of course, you can set locks, right? So in my calling code I have:

my $lock = My::Lock->new(blah => blah);
$lock->set();
[download]

Well, I forgot about OIO's ->set() Class method that is used for setting attributes inside class code. And, of course, I'm using that exact Class method inside a private method in Lock.pm which is itself called by my regular public method ->set(). So, of course, I've got a recursion nightmare. Add to that I accidentally had my $self = @_; instead of my $self = shift; for that private method, and man do you have a puzzler.

So I was unintentionally overriding a Class method in the same class that I was counting on using the parent level method. All with a scalar return context problem for the object ID to throw me off even more.