Wedge

I still can't think of a solution that would really benefit from using goto versus well written non-goto code; the only example I can see that might be viable is the use of it for multiple breaks but even that doesn't strike me as massively easier to follow.

Me :P

The terminology you propose is good :)

In other news, the configuration I need/want is sufficiently special, that I'm going to be compiling PHP from source, I haven't done that in years so I feel somewhat nostalgic.

For those wondering what the hell I could be doing to need PHP home compiled, let me sum it up thus: the application stack isn't Apache <-> PHP <-> MySQL, but... nginx+NHPM <-> FastCGI <-> PHP <-> MongoDB

Yes, this is special in so many ways... and FUN :D Especially since each of those elements has to be compiled by hand for the magic configuration I need >_<

I've been looking at PHP 5.3 today, never really touched it before since prior to what I'm doing this moment, everything had to be reasonably compatible, which meant being less bleeding edge, but what I'm working on tonight is something I'm running myself so I thought I'd look at PHP 5.3.

Overall, vs 5.2 there's little there I think I'd use but it's nice to see some of what they're adding. What did catch my eye however, was this: http://uk2.php.net/manual/en/control-structures.goto.php

The picture at the bottom for one, but more relevantly, why the hell did PHP's devs think adding goto was a GOOD idea?! Seriously... I haven't yet found a situation in PHP where a goto would be the truly best answer.

I foresee this causing lots of bad mojo with PHP which it was doing so well at shaking off.

That's called $context :PIt's an interesting idea but not entirely practical, mostly because there's already $context, and partly because hooks are there for a specific purpose, not just a convenient place in time; the actions hook for example is there specifically to be used with modifying the list of actions.

Anything already in $context, $settings, $options, $modSettings etc is already available if the hook wants it, it's only really if the hook needs to send something through to the hooked function that's not a global scope, e.g. the list of actions, or if calling the new-topic one, the details for the new topic and so on.

Really, pushing things to a 'global local' function is bad juju because really one thing I want to do is empty some stuff out of $context rather than fill it up more.Faster, yes, more likely to collide with new local (temporary) variables but no real issue either way. Pruning only helps with saving memory in low memory configurations; it isn't an issue normally.Sure :) Though a fair amount will be anticipation as well, I have a litany of mods in mind that I'm constantly thinking... "how can I make that work without editing the code?" That's really my baseline when I'm thinking of the changes to make.Yes on both counts.I'm actually fine with it here, because I want to not only explain why things won't work but also the rationale behind the level of changes we're doing and the real benefits of hooks - while I'm actively going to be encouraging hooks, I want people to understand not only the 'how' but the 'why' as well. Remember, those modders who migrate from SMF are going to initially want to reuse what they've done before, and while I'm not planning on pruning the package manager that far, I really don't want to encourage them to continue bad habits. I want them to learn new ones, better ones, ones that will help them grow as developers, knowing as I do that most mod writers are not professional grade programmers.

For the project I've been on for 2 1/2 months, I'm slowly getting towards a resolution, which is rather nice, but the hardest part of what I've been doing is compositing divs in the DOM. (Don't worry if that sounds technical; it's just a fancy way of saying about putting what look and act like mini-windows into the page and making them sort of independently manipulatable)

But IE keeps coming back to bite me in the ass; I do the principle dev in Firefox, test in Opera, Safari, Chrome - works fine. But IE8? I've had to fudge so many little bits and pieces just for IE's stupidity (like for instance, a lack of max-height... it's been in the specification for YEARS)

So when in doubt...


IE is Being Mean to Me

SMF's integration hooks were mostly useless up until 2.0 RC4 wherein they were upgraded to support multiple functions being called at the same point in the execution.

We're keeping most of the existing hooks and adding a lot more of them generally, and combined with SMF's general structure of keeping the current running state in $context (while we'd like to phase that out, doing so is less than trivial), means that you can manipulate an awful lot of things whilst running in the hooks without having to do any editing of the code itself.

So yeah, we're not getting rid of them, we're jugging a few around and adding plenty more.

We've been asked this more than once, so I thought it was about time I answered it.

The short answer is no: SMF mods and themes will not work properly on Wedge without significant overhaul, and this is completely intentional.

It's not about being petty and intentionally breaking it just to annoy people, there are major factors that we sat down - both of us being experienced mod writers - and decided we wanted to tackle.


SMF mods explicitly rely on the code, a mod package is really just a set of find/replace instructions on the code. The only way to retain a reasonable level of compatibility with SMF mods is to not change the code. It isn't ideal, of course, but it is the only way to go about that in the SMF world.

This causes multiple problems, file permissions giving everyone grief, as well as more and more mods being installed causes them to collide further and further until the point where mods just refuse to install because the code they look for has already been installed.

Add to that, that mods on custom themes are at best variable in terms of success and you find yourself in a world of hassle after a while, even when you're using mods written by people who know the code well enough to avoid most of the trouble.


The consequence is a serious amount of rearchitecting the core of SMF in Wedge, to make it far less dependent on mods having to edit the code itself. The downside is that in the short term, users may find a restricted choice of features available to them, while modders learn how to leverage the power of modding in Wedge without code editing.

As for themes, the amount of change is smaller, but still we've made a large number of changes to the default theme, meaning that any theme will need reworking for Wedge as well, but the compatibility should be greater in the long term.


tl:dr; No, themes and mods won't work. But for the hassle of modders and themers learning how to work on Wedge, everyone wins because you'll be able to drop things in with less hassle (if they're written properly), and both the modders and themers should find there is a lower support requirement because the base is that much more flexible.
Also, we will document the main changes we made, so that modders can easily adapt to them.