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.

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.

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.

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.
#
[download]

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