Adding phpbb prefix to functions

[nickvergessen]

Both options would preserve compatibility for upgrades, but the second option, for fresh installs, having it disabled would require administrators to enable it if they want to attempt to install old modifications.

I don't see any advantage in bugging the user with this.

I'd vote for bantu's thing:

fix functions to:

Code: Select all

phpbb_abc($db, $parameter)
{
    ...
}

and add wrapper:

Code: Select all

abc($parameter)
{
    global $db;
    phpbb_abc($db, $parameter);
}

[MichaelC]

Both options would preserve compatibility for upgrades, but the second option, for fresh installs, having it disabled would require administrators to enable it if they want to attempt to install old modifications.

I don't see any advantage in bugging the user with this.

I'd vote for bantu's thing:

fix functions to:

Code: Select all

phpbb_abc($db, $parameter)
{
    ...
}

and add wrapper:

Code: Select all

abc($parameter)
{
    global $db;
    phpbb_abc($db, $parameter);
}

It just makes them easily disablable if there are then clashes between different softwares and the user doesn't care about supporting pre-3.1 modifications that may use old function names.

[EXreaction]

I do not think the user would be bugged with a config constant.

With the config constant:
Users who upgrade would maintain compatibility automatically, so if they do have any old modifications they wish to try using they would not fail because of functions that were renamed.
New installs would have the constant in the config file and the compatibility file would not be included by default. That would prevent compatibility issues with other software and keep the global function namespace cleaner and, as long as they do not try installing 3.0 mods, they should not run into any instance where they need the compatibility file included (to change the constant).
In the case users want to try installing old mods, they would need to change the setting on the constant to enable "compatibility" mode and include the wrapper functions.

Only fresh 3.1 boards where admins want to attempt installing 3.0 modifications do admins need to do anything (we need to make sure admins are aware of this constant and what it does then, but they should be expected to be able to handle changing this if they want to try 3.0 mods on 3.1).

Without a config setting (include the compatibility file by default):
Compatibility file is included, but it's possible that use with other software could cause function name conflicts, even when these compatibility functions are not needed.
No issues for owners who want to attempt to install 3.0 mods with upgrades or installs.

Without a config setting (do not include the compatibility file by default):
Less likelihood of function name conflicts, cleaner namespace.
If the compatibility functions are needed, board owners need to modify their code to include the file and mods need to be updated to include the file or use the new function names.

I really believe the first option is the best of both worlds. Having a compatibility constant may be useful for other things in the future as well (although I cannot think of specific instances right now).

[bantu]

I don't know. Users should be told that their modifications are outdated and should be ported to 3.1. Users should have to do manual work in order to turn compatibility mode on, it should not happen automatically.

Doing it via a constant might make sense, but because we still have multiple front-controllers and not all of them include common.php.

Also, we should consider what happens when 3.2 gets out and we need another compatibility file.

Also, modifications will break anyway when upgrading from 3.0 to 3.1. E.g. some classes have been properly redesigned with new methods, some global variables have been renamed.

Also, maybe boards using compatibility mode should not receive support because we do not test the compatibility layer well.

[EXreaction]

Of course, board owners will need to be told that 3.0 modifications have a good probability of not working in 3.1. But if it installs with Automod it *should* work properly.

We have to think of what is the least likely to cause confusion and additional support requests from the people who use the software. It is very likely people will try installing 3.0 mods on 3.1 and many mods may install fine, but if they start throwing errors after that it will cause additional support issues. Preventing these errors, which can be done depending on the decision made here, should be used in making the decision on what is to be done in our product.


What front controllers do not include common.php?

The compatibility functions can be appended to the end of the same compatibility file used in 3.1. We should make sure we have enough of a time frame to depreciate the functions, at which point the older wrappers may be removed (e.g. in 3.3, wrappers for 3.0 functions are removed, in 3.4, wrappers for 3.1 functions would be removed).

Not all modifications will break anyways, I know a few of mine alone that should work perfectly in 3.1 without changes. I do not know of any publicly used methods being changed or globals that have been renamed, can you give any examples?

Compatibility mode only creates wrapper functions, I do not see how these would make any difference for support.

[brunoais]

I prefer the option of joining my idea (I didn't really know what was wrong with it) with bantu's minor changes/adaptations (basically, get rid of the global scope and send all values through parameters) and using EXreaction's first idea for a config constant that turns this adaptation on and off.

[callumacrae]

I prefer the option of joining my idea (I didn't really know what was wrong with it) with bantu's minor changes/adaptations (basically, get rid of the global scope and send all values through parameters) and using EXreaction's first idea for a config constant that turns this adaptation on and off.

Your idea is completely and utterly pointless. The entire point in renaming the functions is to prevent naming conflicts; by keeping the old function name used, it ceases to solve the original problem.

[brunoais]

I prefer the option of joining my idea (I didn't really know what was wrong with it) with bantu's minor changes/adaptations (basically, get rid of the global scope and send all values through parameters) and using EXreaction's first idea for a config constant that turns this adaptation on and off.

Your idea is completely and utterly pointless. The entire point in renaming the functions is to prevent naming conflicts; by keeping the old function name used, it ceases to solve the original problem.

You can't see it, don't you?
This is meant to be made for the next 1 or 2 subversions for MOD/extension makers adapt their code to these changes. After those, we remove the stub functions and we'll get all functions (and classes, if needed) prefixed.

[EXreaction]

I prefer the option of joining my idea (I didn't really know what was wrong with it) with bantu's minor changes/adaptations (basically, get rid of the global scope and send all values through parameters) and using EXreaction's first idea for a config constant that turns this adaptation on and off.

Your idea is completely and utterly pointless. The entire point in renaming the functions is to prevent naming conflicts; by keeping the old function name used, it ceases to solve the original problem.

Callum, please see the other posts in this topic. This is for compatibility reasons.