Re^2: Are sub/method synonyms acceptable coding practice?

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

Comment on Re^2: Are sub/method synonyms acceptable coding practice?

Replies are listed 'Best First'.
Re^3: Are sub/method synonyms acceptable coding practice? by Tanktalus (Canon) on Nov 19, 2005 at 16:10 UTC
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.	[reply]
Re^4: Are sub/method synonyms acceptable coding practice? by rcseege (Pilgrim) on Nov 19, 2005 at 17:23 UTC
I agree with the `isInGods` approach, but I think if I was coding something like this, I'd make it even more explicit -- something like: `isMemberOf` to show that the method was explicitly checking membership. Then again, I don't really know the details of how it's being used. It's probably a very specific case that doesn't need to be support multiple groups. As for aliases, I think when used in moderation, perhaps it could be valuable, but it's a practice that can easily get out of hand, and add to the burden of someone else who is reading the code. In Tk, for example, when creating your own custom widgets, it's possible to create many different aliases for option names. These aliases usually are a shorter form of the option name (-background becomes -bg), but that isn't always the case. Sometimes they are different names entirely (-choices or -items). There are different reasons why this is done, but in the end it means that there are more different names that basically mean the same thing, so that someone reading the code has to be aware of both, and may wonder are these two calls/options really the same thing, or are they subtly different? I think the same would be true with subs.	[reply] [d/l] [select]
Re^3: Are sub/method synonyms acceptable coding practice? by mojotoad (Monsignor) on Nov 21, 2005 at 23:19 UTC
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	[reply]


Perl-Sensitive Sunglasses
	PerlMonks