http://www.perlmonks.org?node_id=510078

Today I was doing something on the site, and did a mistake I often find myself doing. There is a routine called isGod() which I have a habit of spelling isGods(). It occured to me it would be nice if isGods() was a synonym of isGod() so it wouldn't matter, especially as isGods() isn't that unrealistic a name for what the routine does. But on reflection it seems to me that this maybe isn't the best idea, just making code less clear to read. But then it occured to me that its not entirely uncommon to see synonyms for routines named after words that are spelled differently in American and British english, such as color/colour and words ending in 'ise' and 'ize'. So there is some precedent for this kind of thing.

I wonder what the monastery thinks of this practice. I mean how far should one go with this? Especially when you consider other languages beside English, or other aspects of this issue, such as mistakes like mine.

---
$world=~s/war/peace/g

Replies are listed 'Best First'.
Re: Are sub/method synonyms acceptable coding practice?
by dug (Chaplain) on Nov 19, 2005 at 21:49 UTC

    The only time I've justified this kind of aliasing to myself in the past was when I realized that I had inconsistent method names in my published API and I wanted to make them consistent in a backwards compatible way.

    In the instance I'm thinking of, all my action methods were named verb_noun except one. Instead of changing the API I felt it was better to provide a verb_noun alias for the one noun_verb method.


    -- Douglas Hunter
Re: Are sub/method synonyms acceptable coding practice?
by perrin (Chancellor) on Nov 19, 2005 at 20:02 UTC
    I would avoid it. It just makes the code harder to read for someone who doesn't already know that these things are aliases. They have to look it up twice, once for 'isGod' and again for 'isGods'.
Re: Are sub/method synonyms acceptable coding practice?
by johnnywang (Priest) on Nov 19, 2005 at 18:21 UTC
    I'd vote against aliases, partly because it's rather difficult to make it consistent (sort of similar to abbreviations). And in this age and time, half of the people use some kind of IDE that pops up the method choices. For those of us who don't use IDE, it's more important to give meaningful names than to give multiple names. Just my opinion at the moment.
Re: Are sub/method synonyms acceptable coding practice?
by Aristotle (Chancellor) on Nov 19, 2005 at 14:44 UTC

    I think it’s a good idea for an author of an API to offer a few aliases (with moderation!). I think it’s a good idea for a user of an API to pick one of them and stick with it.

    Makeshifts last the longest.

      I completely agree. And, where there is more than one user using the API in a single application I think they all should pick the same one and stick with it. So, in demerphq's case, I think creating an alias is probably a bad idea.

      -sauoq
      "My two cents aren't worth a dime.";
      
Re: Are sub/method synonyms acceptable coding practice?
by tilly (Archbishop) on Nov 19, 2005 at 22:03 UTC
    Well if you want to go as far as davorg, you write a module to catch lots and lots of variations automatically. :-)
Re: Are sub/method synonyms acceptable coding practice?
by rir (Vicar) on Nov 19, 2005 at 22:41 UTC
    My guess is that the code you are dealing with doesn't have that many coders and so doesn't warrant such aliases. But this is an issue to be decided by the development team.

    I tend to tough it out in such situations--sharing a vocabulary promotes communications; adapting promotes flexibility of thought. I get interrupted enough that maintaining flow is pretty hopeless.

    Perhaps you could wedge something like this into your checkouts:

    #!/usr/bin/perl use warnings; use strict; # rirs_lib sub A::isGods { use Carp; carp "Warning: rir's idiocynatic call s/b isGod$/"; A::isGod(@_) } package A; sub isGod { local $,="|" ; print 'You are God ', @_, $/; } sub new { bless {}, 'A' } package main; my $g = A->new(); my $what = "what"; my $else = "else"; $g->isGods( $what ); A::isGods( $what, $else ); __DATA__ Warning: rir's idiocynatic call s/b isGod A::isGods('A=HASH(0x814ccd4)', 'what') called at ./xx line 30 Warning: rir's idiocynatic call s/b isGod A::isGods('what', 'else') called at ./xx line 32 You are God |A=HASH(0x814ccd4)|what| You are God |what|else|
    Be well,
    rir
      Perhaps you could wedge something like this into your checkouts:
      Checkouts? Is that some fancy version control concept? How quaint.
Re: Are sub/method synonyms acceptable coding practice?
by BUU (Prior) on Nov 19, 2005 at 12:55 UTC
    Going completely off topic from your post, but I'm now extremely curious. Why do you have a subroutine named isGod? What does it do? Inquiring minds want to know!

      Its not unusual to want to tell if a user is a member of gods*. In my case I wanted to use it as a convenient flag to make an xml feed return some diagnostic data. Other reasons are to enable access to extra controls in various places for administrative purposes.

      * this is probably the cause of me doing isGods() and and not isGod(). I think of it as a membership test and not as an attribute of the user. To me isGod() implies attribute, but isGods implies membership. Its only a point of view tho, I can see others not agreeing with this.

      ---
      $world=~s/war/peace/g

        While this isn't strictly on the original topic, it's not strictly off-topic, either. Perhaps this mental confusion is because neither one is a perfect name. In a case where you can't come up with a perfect name, aliases may be warranted, but in cases where a better name exists, perhaps just moving the code to the new name would be better. In this case, I'd suggest "isInGods" as a potential alternative. This all does stem from the fact that a member of the group gods is a "god" - so the flag and the groupname don't match. The same problem does not exist for pmdev (if the group were named "pmdevs" it would), but does for others, such as holders of unholy power or breathers of fire. The "isIn*" idiom would hold for all of the groups, whether they changed name or not.

        Taking this a bit further off topic...(well, not really, I suppose you could make an argument for aliasing declaritive verbs with prepositions in your method/sub names, but that's not my point):

        Given what you describe, I probably would have called the method 'in_gods' (or inGods if you prefer that kind of thing).

        Cheers,
        Matt

      package Everything::Node::user; ... ###################################################################### +####### # Sub # isGod # # Purpose # Checks to see if the given user is a god (in the gods group). # # Parameters # $recurse - for speed purposes, this assumes that the gods gro +up # is flat (it does not contain any other nodegroups that it + would # need to traverse). However, if the gods group does conta +in # nested groups, you can pass true here to check everything +. # Note that turning this on is significantly slower. # # Returns # True if the given user is a "god". False otherwise. #

        Perlmonks is on a different fork than that. Our isGod() lives in Everything::NodeBase and doesn't allow for usergroups to be a member of gods. If you want the recursive version on PM you need to use isApproved($USER,'gods').

        Afaik the permission systems on PM and Everything are now somewhat different. We have something called an accessrule which is used to make isApproved() more flexible and powerful.

        Maybe you know all this, but since you are anonymous I can't tell. :-)

        ---
        $world=~s/war/peace/g

Re: Are sub/method synonyms acceptable coding practice?
by dragonchild (Archbishop) on Nov 19, 2005 at 16:16 UTC
    I often offer aliases, especially where it may make code easier to read. For example, in Tree, there's an add_child(). I haven't done it yet, but add_children() could very easily be a synonym for add_child() because add_child() takes any number of children as arguments. Same with remove_child (remove_children), has_child (has_children), and find_index_for (find_indices_for).

    One of the weaker criticisms of Ruby is that it offers too many aliases, making it harder to read someone else's code. I actually find that there aren't enough aliases, but that's just me.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re: Are sub/method synonyms acceptable coding practice?
by spiritway (Vicar) on Nov 19, 2005 at 23:16 UTC

    I think one question to answer is "who's paying for your work?" They'd have the right to say whether this is acceptable practice. If you're working for free, but in a team, then the team ought to have some input.

    I have always found aliases confusing, so I don't like them. That's just a personal prejudice, though.

Re: Are sub/method synonyms acceptable coding practice?
by diotalevi (Canon) on Nov 19, 2005 at 19:56 UTC

    Isn't there a module that does this already? Something using Lingua::EN::Inflect? There's a key difference though between something that is singular and plurar - you expect to be able to pass more than one to a plural function. This might mean a different calling convetion like func( $elt )/func( \ @elts )/func( $elt1, $elt2, ... ) and it isn't obvious which one would be used since there's no convention for that kind of thing.

Re: Are sub/method synonyms acceptable coding practice?
by shotgunefx (Parson) on Nov 20, 2005 at 10:59 UTC
    Don't know about this particular example, but I think it's ok in moderation, where it makes sense. The times I've done it, the names aren't usually so close. More to fit two different ways of thinking about a problem.


    -Lee

    perl digital dash (in progress)