[TYPO3-core] Class namespaces with 6.0

[Christian Kuhn]

Hi.


There were lots of requests and rumours about proper php 5.3 class 
namespacing for the TYPO3 core in the past and things started to happen 
at several community events and in the wild.

The most promising approach is lead by Thomas Maroschik. During the code 
sprint in Freiburg, Thomas with some fellow people worked on this evolution.

Susi, Helmut, Olly, Christian and Thomas Maroschik had a skype meeting 
with the topic 'TYPO3 core with namespaces for 6.0' today.

In the first place: We all think that namespacing gives us a chance to 
boost the core to a new era and is fully in line with #backToTheFuture.

So, what do we aim for?
- Goal is a clean namespacing for all classes in the core, for example 
under main topic '\TYPO3CMS'
- Goal is to become more close to the FLOW3 project, we want more easy 
transition of code, and maybe even load packages from FLOW3 as is, or 
the other way around
- We want no more naming clashes
- Goal is a clearly separated and indistinguishable naming scheme for 
all core and core extension classes
- Goal is to get rid of evil class names that do not say a thing like 
't3lib_div' or 't3lib_tsStyleConfig' or 'tslib_content'.
- Goal is to define an easy definition for namespaces like 
\vendor\extension to further reduce possible clashes

What does it mean?
- All class names will be within an own core vendor namespace like 
\TYPO3CMS, we are in contact with the FLOW3 team to sort out details, so 
that we won't have problems in the future
- Namespacing for extensions will be mandatory, but with a compatibility 
layer
- All class file locations will be moved around, the autoloader will 
find them
- Extension authors must adopt to this technology, but there will be a 
compatibility layer that works, there will be a transition time, we will 
not break 99% of extensions

Actions to be taken:
- Every single class needs to be tackled and a sane decision for a new 
name must be taken
- All calls must be adapted to the new naming scheme within the core
- A reliable deprecation scheme must exist
- We must solve special circumstances like currently multiple defined 
class names
- We need a clean documentation on how naming is done, used and expected.


We will not deliver a 6.0 without a sane (eg. only one msg. per http 
request) deprecation and compatibility layer!


We will have a sprint on the 'find final class names' topic with Thomas, 
Olly, Susi and Christian on the 4.8. in Nuernberg. Thomas already has a 
reliable script to rename / adapt core calls. After final decisions have 
been done, we want to integrate everything in the period around feature 
freeze and the release of 6.0 beta1.


We are all looking forward to get this done. If we manage to keep 
backwards compatibility together with a new class scheme it would be a 
great leap forward for a more modern core. With 6.0 we have the chance 
to do that once and for all, so lets get it done!


Regards
Christian