Wedge

I'd also like to create a cx (context) object. Not with the usual 'we' prefix, I know, but the idea is to keep it very, very short, and 'we' is already taken for the system class, although we MIGHT be able to use 'we' instead and just have we::$user behave like if it is was $context['user'], or whatever.

The main problems are:
1/ Performance. $context is used in TONS of areas, including time-critical code, so it's going to be hard to tell people to use 'cx::$var' instead of '$context['var']' in these areas. So we'd need to keep having a global point to the array.
2/ Because of (1) and general laziness from devs who might have $context so deeply carved into their DNA, we could/should/might use $context =& we::$cx, or cx::$cx, or something, but that means we can't use cx::$var, but instead we::$cx['var'], which only saves one byte compared to $context['var']. We could go as far as we:$c['var'], but even then, it's a bit ugly and all anyway...
3/ Some people might argue that we could simply rename $context to $cx, and be done with it, accept globals and that's it. :P

I'm looking into other solutions... So far I've found a strange one, which could work but only for variables that never change...
$context = get_object_vars(cx::getInstance());

This will effectively transform cx::$var into $context['var']. Seriously. But I'm guessing that, even without benchmarking it, this function call is not 'free' and thus can only be done on purpose at one point or another...

Ahhhhhhh... If only accessing a singleton variable was just as fast as accessing a global var! Why does it have to be about 60% slower..?!

Oh, take your time...
I have a feeling Wedge final won't be out for a while... :whistle:

(And we still haven't released Alpha 3... >_<)

The we object is actually not finished at all... And it shows ;) I'd already made a few more changes to it even before you committed your changes... Thankfully, no conflicts. But still, I was heading towards something else. I guess it always feels strange having someone tell you how to code when you're right in the middle of it... I have my pride, as you know :lol:

I too am obsessional (is that even an English word?) about consistency. And because I'm also obsessional about keeping code as tight as possible (as long as it doesn't impair readability), in this case it was bound to clash with your obsession about documented code ;)

I can understand that.

Hmm... I'm trying to make a quick review of all other possible phones I could get my hands on... Apart from the CloudMobile (which has the advantage of being so cheap I can survive seeing it break if I drop it by mistake...), I don't really see anything convincing. Meh...

Well, still, there's a reason why I went from my iPod to an Android phone, and survived the idea of no longer having my Scrabble app (which I played something like a thousand times in tw oyears), or my Monopoly Hotels app, in my pocket... And it's not just because I get extra freedom.

It's just that I'm into innovation, like you are. My iPod was innovative two years ago. But right now, if I want to replace it for a similar price, I can get the same machine, a tad faster, a few grams lighter, a centimeter taller, and way uglier. That's not innovation to me... When for the same price I could get a machine that's twice more powerful and actually allows me to phone as well.

Anyway...

A real group with ID 0..? It doesn't make (too much) sense to me.
I'd rather have an extra group added by the installer (or importer), and everyone with group 0 would be put into it. It would simplify code refactoring a lot because you don't actually need to check everything again.

Size matters. Hence my $user_info rewrite, among other things...

PHP won't make protected the default, if anything to keep it backward compatible with older scripts.
So, yeah... To me, it's the same thing. PHP regularly adds new optional parameters to their functions. You don't need to specify these parameters, they're only there if you want to change them. So, when it comes to objects, it's the same to me: the simpler, the better. If you need to change a function's scope, you can. Otherwise, you don't have to...

Thanks for bumping that topic, one of many I'd missed... (Would probably have found it if it had a more explicit name :P)

Oh, Noisen.com actually had from day one a specific 'regular members' group where all new members were put it. IIRC, it's nearly built into SMF itself, you just need to change a line or two in Subs-Members.php or whatever, in the registration function, there's a place to force a membergroup for new members. So, that's what I did... And it's easier to manage.

It'd be nice to move all members into a special group indeed. But how do we do that on import, eh...