Wedge

You guys know how to make me feel like a young kid again :P

We're not above the law, but we will be ethical and measured in all that we do.

Only last night I encountered a change in behaviour between my local PC and the server that my code was deployed onto; it was a schoolboy error on my part for forgetting it (call_user_func_array expects the callee to be specifying its parameters explicitly as references, rather than values, especially given that the caller was using references) - on my 5.2 setup it worked as expected, on a 5.3 box it broke quite interestingly.The reason it doesn't matter in the SMF world is because so much of what goes on is DIY coding rather than letting PHP's own functions do the job. Number formatting, timezone offsets, time generally, etc.Interesting. Having actually done something lately[1] that would be applicable under this discussion, let me step through what I did and why - then we'll see if it was the right decision for the case in point.

So, I needed something that would operate during the SD ticket load phase and then proceed to add a template in. Since I'm slightly lazy and had no desire to force yet another file to be loaded when the template was a very simple one, I just put the source and template in the same file.

I actually figure most mod authors would do the same if they could get away with it. Most mods don't bother trying to support all different themes, concerning themselves with template edits, or for bigger/independent stuff, a separate template file.

Embedding the template itself into the mod would prevent creating a separate file just for separation's sake because the point of MVC isn't about putting files randomly in different places to separate the code, it's a pattern: that you keep presentation and logic separate as far as possible, and even if you're mixing them in the same file, you're still logically separating them into separate functions; it would only be an issue semantically if you had just the template with the logic in it.

So, getting back to the point: I'd suggest we don't have it load files in template hooks. Any new template will require code to back it up anyway, which means you're going to be loading a file to engage the logic-powering hook anyway, and that new file can load a template if it wants, or it can embed the template if it wants. Then if the mod wants/needs theme specific changes for some random reason, it can be left to the mod author to make it happen if they so desire.

1.	A custom SD plugin, as it happened.

I know people who regularly use the term 'couple' to mean 3 or 4.

It is a few... depends on your definition of few vs several vs some vs many, really, but the definitions are flexible :)

Yes: some versions of the locales database don't set everything properly when using just LC_TIME, going off the comments in the setLocale manual page. http://www.php.net/manual/en/function.setlocale.php#77795 mentions it for example.

Windows aside, which is buggy anyway and I wouldn't expect serious users to be running PHP on Windows as a consequence, setLocale is threaded, meaning that there are no outbound consequences for doing the switch as suggested; once it enters the CSS parser, it's going to remain there until it's done.

I'm happy to try it as suggested, especially since now I read up on it again, I don't see how we can make use of LC_COLLATE or LC_CTYPE because that has implications for users migrating from other systems (since those affect how strtolower is done and how string comparisons may be made, though equivalence checks shouldn't be affected) though some things like LC_MONETARY might be useful in places.

It's, unfortunately, a case of swings and roundabouts :/

All we need is a Time Lord to throw the scales off anyway ;)

This is where it gets complicated. As I discovered when testing with large datasets, I discovered that having everything in a single master table actually does hurt performance because you just can't make use of the indexes the ideal way - by segmenting by board, you get to instantly drop a decent percentage out of the index.

500m topics in a single board when that's all I had, really hurt compared to 1.5m topics split by three boards.

The more that can be kept out of the main table, or at least efficiently indexed the better. If we have two columns filtering the status, the index probably won't be that efficient - it would probably be better if we were to index on a single column with all four (approved/not approved/deleted/not deleted) states in a single column, it would probably index better, but benchmarking will tell us for sure.