Wedge

I'm not trying to dictate how code goes, as such, just that I like code cleanliness, and to me code that clearly indicates its scope is more clean than relying on PHP's rather idiosyncratic approach. There's an excellent article about how messed up PHP is in that respect, so anything we can do to make it make sense is better.

I'm not disagreeing that Apple haven't innovated the last few iterations ;)

For what purpose, though? What would you do with this extra group?

Group 0 MUST by definition exist anyway. I'm just trying to avoid creating an extra group that would do exactly the same thing that you're proposing, only without making an extra group to do it.

Consider what you've just said now imagine that it happens to be number 0 instead of number 9 or 10. You still have to do all the same checking you would before.

This is the thing... it's solely the way it is because of older scripts. There's been an argument ever since PHP 5 introduced it that it should have made scoping mandatory, and in fact prior to PHP 5.1, it would have actually tripped a E_STRICT warning.

I get the whole size thing, but quite honestly, there are other things that are as important as keeping it minimalistic, like keeping it readable. Besides, I still want to make phpDocumentor documentation and it will not like the lack of explicit scoping directives.

Better question is *why*.

As the DB structure stands, we *have* to provide a group for users to go to. Group 0 absolutely has to exist in some fashion. All I'm essentially doing is converting from being a phantom group into being a real group, albeit one that you couldn't remove.

What you do with S&B is have a single textbox in the admin panel where you indicate what badges to be displayed. E.g. if a user is in groups 1, 4, 10 and 20 (4 being the post count group), you could indicate 1,10,20,4 in the admin panel to display those groups if users are in them.

The big difference is that in S&B you just say what badges to display out of all of them and you set the exact display order.

If you don't declare the scope, they're automatically public anyway. I just made it explicit rather than implicit. I'm not sure PHP does parse it faster - it's actually historical hangover from PHP 4 when OO didn't have scoping. Aside from that, it's simply good practice.

As far as $options = & we::$opt or whatever, that's fine, but the goal should be eventually to remove it. Global variables are not actually that clever.