- The trigger check is so not being optimized for performance:https://area51.phpbb.com/phpBB/viewtopic.php?p=271217#p271217 wrote:This call is sub-optimal, and I don't know why this call pattern has evolved. Cons:
Code: Select all
extract()is slower than i.e.
foreach() $$var= $value
extract()might fail when incorrect data is passed. Documentation comments say it fails for everything, including data which might be processed/parsed correctly.
compact()creates variable copies - why not directly using references? That would also kill the need of
- Both functions are always called (including all the work they do), even if they're not needed at all (no event matches to be triggered). Why not having an implementation where an
iffirst checks for trigger matches and only after that all the extract/compact work is done? Considering how many times event trigger checks are encountered (and will surely increase in future releases) this is a questionable waste of overhead.
- While the trigger/extensions approach works for reducing (core) file changes, it is ill-conceived: you can have snow ball effects (extension code by one trigger can (re)match dozens of other triggers without hinting there's no need to (re)match anything else); just adding more hook points will never fully cover all needed cases, not to speak of preventing phpBB code lines from being executed (conditional jumps); ...
In the end the question comes up why phpBB doesn't use triggers itself and surprisingly it turns out that not everything can be solved by adding trigger hooks.
- Relying on external frameworks comes with relying on bugs/threats on that external software. [...]
- The code has become less traceable because of auto-loading classes and configuration files - calling
debug_backtrace()is not always a help.
This is exactly how I feel but my hosting company (Arvixe) is very good at maintaining past versions of php and letting the user select what version is needed. They maintain 5.2 and last check have no intention of dropping it.Pond Life wrote:I would rather stick with 3.0.14 for all the reasons stated above but I do worry about what will happen when my hosting company updates php to a version that is no longer compatible. For example, viewtopic.php?f=64&t=2316556, I know it's not imminent but it will happen eventually and by that time the update may be even more problematic than it was when I tested it recently.
If someone were to do a fork to keep 3.0 working on future php versions it would make the choice much easier. Unfortunately it's a task that's above my current abilities and I don't have enough spare time to try at the moment.
Ranch Dog wrote:I do hold that first group in high esteem as they have made it very easy for the second group to enjoy their work.
I manage 3 sites, 2 of which I was able to update to 3.1 since they didn't use that many MODs on 3.0 (all of which I was able to code myself as extensions). The 1 site still on 3.0 is so integrated into other parts of the site that it's simply not feasible to convert over. There's been code removed, code added, dependencies on other site functions, etc.Ranch Dog wrote:making the change to 3.1.x will cost my users some of the features that they enjoy now
Too many cooks spoil the broth. And one idiot in the team can ruin the whole work. I already met persons that cause more work than they processed.Mess wrote:more active developers [...] more secure and with less bugs
After all it's not a big deal to adapt all code parts to run for PHP5.6 or PHP7. I'd even start right away doing so, but we're co-hosting an old vB version that I already had to patch manually to be run on PHP5.4, and I have little interest in diving into that horrible code again to make it i.e. PHP7 compatible.Pond Life wrote:what will happen when my hosting company updates php to a version that is no longer compatible