[TYPO3-core] Minutes of the 6.0 release team meeting

[Anja Leichsenring]

Hi all,

during the extbase code sprint wie implemented a basic namespace 
awareness of the autoloader. The patch is currently pending [1].

It enables the autoloader to handle class names like 
"\Tx\ExtensionKey\Foo\Bar", find the containing class in 
"extensionkey/Classes/Foo/Bar.php" and require it.

@Thomas: Do wie need more prefixes like \Typo3 and \T3lib or others?

[1] https://review.typo3.org/#/c/12944/

Best regards
Anja

Am 19.07.2012 12:32, schrieb Thomas Maroschik:
> Hi Jigal,
>
>> Which spreadsheet?
>
> See here:
> https://docs.google.com/spreadsheet/pub?key=0AjQjYvMWGLr4dHZlb0oyWF9YZVdudk9zREdXQU1hYkE&single=true&gid=0&output=html
>
> If you are willing to contribute to this list, get in contact with me
> and I'll share a editing link.
>
>> How much performance is this going to cost?
> The new class loader will not cost more as it currently does with it's
> autoload registry. If extensions require() files instead of using
> autoloading, there can be minor performance issues. As the class alias
> function is a builtin function, I expect it to be fast.
>
>> Which basically means that we need separate versions of *all* extensions
>> for 4.x and for 6.x? That's not going to happen.
>> * most extension authors will not make updates until some time after
>> things really break. In the mean time hardly anything is working. This
>> means that if the original classes will be removed in 6.2, it basically
>> means that any upgrade to 6.2 will be broken for many months.
>> * TER and the IM are not capable of keeping both branches apart. It will
>> suggest the latest version for 4.x too, which will not work
> This is not necessary (see next comment). New introduced extension that
> aim for 6.0+ versions can use the new naming scheme.
>
>> Getting this to work with new class names would require a forward
>> compatibility layer in 4x too. I'm not sure the RMs of those versions
>> are willing to introduce this, especially because it could very well
>> influence stability of those versions.
>
> I'm not expecting extensions to adopt the new class names until 6.2 if
> they should work also on 4.X. By that version all 4.x Versions become
> obsolete and extension authors can start using the new class names. The
> old ones can continue to work until 7.0.
>
>> What is the use case for this?
>
> It's a chance to clarify the concerns of the distinct classes and path
> the way for easy forward- and backporting to FLOW3/Phoenix. The core
> gets easier to understand for new developers. As v4 continues to live in
> v6+ it would also be a signal to the PHP world, that the community is
> interested in code quality and getting rid of legacy code. TYPO3 has
> plenty of that and the definition of clear class concerns makes it
> easier to identify that.
>
> Regards,
>
> Tom
>