Lets see, the !allow command can only be activated by an OP so lets say we have 1 op and 99 users, every single one of them typer !allow blah
using method (1) there are 100 iswm and 100 isop done
using method (2) there are 100 isop and 1 iswm done
Are you telling me 100 iswm's and 100 isop's are "approximately equal" to 100 isop's and 1 iswm ?
Where did that clause come from? Nowhere before did you ever say that the '!allow ...' text was only relevant if an op says it - you're changing the rules in the middle of the game.
It doesn't really affect what I said anyway, because on most channels I would expect there to be a far higher ratio of
ops[color:red]:non-ops[/color] than there is of
'!allow ...' text[color:red]:non-'!allow ...' text[/color] on a channel. So your example is completely flawed. Yes, if 100 people say '!allow blah' and only 1 is an op then your original assertion is correct, however I can just as easily turn this around and say "
What if 100 users on a channel are all ops and they each say something, only one of them says '!allow blah' - therefore my way is more efficient'. Of course that's a very flawed example also because it's very unlikely that all the people speaking in a channel will be ops.
However, it is far more likely that someone speaking won't be saying '!allow ...' than it is that someone speaking won't be an op, and therefore my original post is still correct regardless of your added 'ops only' rule.
The point of shortcut evaluation is to put the condition that is least likely to be true first with the and operator and the most likely first with the or operator.
Thats a narrow view on its purpose im also not sure if in all cases that even holds, from what I know historicly it originated from coders wanting to put there accessing of something into the the same IF as there bound checking of it, such as beinga able to replace...
Well, no it's not applicable in all cases. If one condition takes an amount of time to resolve that's disproportionately larger than the difference between it and another condition failing then it would make sense to put the faster condition first anyway. However that's definitely not the case with what we're talking about here. Anyway, I didn't mean the sole point of shortcut evaluation existing was to be more efficient by putting conditions in a certain order (although that's certainly a major one), I simply meant that in order to get the efficiency boost that shortcut evaluation offers you should place your conditions in that order.
