Moving to namespaces

[MichaelC]

During Amsterdam it was agreed that we should start using namespaces.

If this is going to be done it probably needs to be done in 3.1 otherwise we will be breaking BC.

Conventions
We should be following PSR-0

There would need to be coding guidelines added with regards to this and the use of use statements https://github.com/php-fig/fig-standard ... clarations and https://github.com/php-fig/fig-standard ... lass-names

Vendor name should be phpBB (That is what we have been using in other sub-projects already for a while).

Must be fully qualified as: \phpBB\<directories\from\includes>\<Class Name>

Underscores are treated as directory seperators so directory structures must be updated accordingly.

Example: phpbb_extension_metadata_manager must now be located in phpBB/includes/extension/metadata/manager.php would have the namespace \phpBB\extension\metadata_manager or \phpBB\extension\metadata\manager. This looks very weird due to our currently casing rules. As such as part of this RFC I propose that all new classes should be StudlyCaps in which case it would become \phpBB\Extension\MetadataManager and methods become camelCase.

Autoloading

We could probably use a library for our autoloader as well instead of updating our current one. The two options I see we have are using composer's autoloading and symfony autoloader. Both use FIG's PSR-0 standard.

There isn't much difference between them, composer was based upon symfony's universal class loader. http://stackoverflow.com/questions/1389 ... autoloader

Symfony Autoloader: https://github.com/symfony/ClassLoader & http://symfony.com/doc/current/componen ... oader.html
Composer Autoloader: https://github.com/composer/composer/tr ... r/Autoload

[igorw]

IMO we should decouple the StudlyCaps discussion from the namespaces discussion, as they are two separate decisions. And presenting them as a package may be harmful.

[MichaelC]

If we are going to change the name of all classes, we might as well do it once and do 2 things than twice?

[Oleg]

If this is going to be done it probably needs to be done in 3.1 otherwise we will be breaking BC.

If this is the only reason I would prefer 3.1 to be left alone and this moved to 3.2.

If you are looking for something to do, may I suggest https://area51.phpbb.com/phpBB/viewtopi ... 19#p249219?

There should not be any new major features started at this point, and I don't want to ask pending patches to adopt this either.

Edit: both studly caps and namespaces.

[MichaelC]

If this is going to be done it probably needs to be done in 3.1 otherwise we will be breaking BC.

If this is the only reason I would prefer 3.1 to be left alone and this moved to 3.2.

If you are looking for something to do, may I suggest https://area51.phpbb.com/phpBB/viewtopi ... 19#p249219?

There should not be any new major features started at this point, and I don't want to ask pending patches to adopt this either.

Edit: both studly caps and namespaces.

It isn't a major feature. It would just be a large diff due to changing all instances of class names?

It's just that if we don't do this for 3.1 then it will probably wait until 4.0 as it will be a massive BC break?

[imkingdavid]

I vote no for 3.1 as well. This will only push back the release further still.

[igorw]

One thing that was not mentioned in this topic is what the original motivation for namespaces was, which we discussed in amsterdam.

The problem with our current autoloading is that currently directory names for classes cannot contain any underscores. And that will be a problem for extensions, because a name like 'who_was_here' becomes 'whowashere'. Namespaces are the cleanest solution to that problem.

[Oleg]

Fixing our autoloader sounds like an easier task. I'm assuming our present behavior is for efficiency reasons?

Is the reason why we initially did not go with namespaces that we were targeting 5.2?

[Oleg]

It isn't a major feature. It would just be a large diff due to changing all instances of class names?

You are going to break all outstanding PRs with this just as we are trying to get them finished.

Are you willing to write a patch before it is decided whether it will go into 3.1 or 3.2?

Amsterdam happened over a month ago. If this RFC is important someone should have posted it in mid-November. Anything else you discussed that should have been RFCed and was not?

[MichaelC]

It isn't a major feature. It would just be a large diff due to changing all instances of class names?

You are going to break all outstanding PRs with this just as we are trying to get them finished.

Are you willing to write a patch before it is decided whether it will go into 3.1 or 3.2?

Amsterdam happened over a month ago. If this RFC is important someone should have posted it in mid-November. Anything else you discussed that should have been RFCed and was not?

Sure but I have no idea how long it will take me to write the patch and test it and therefore whether it will be done for 3.1. It isn't so much complicated as time-consuming going through all the classes. Then checking everything works afterwards.