[TYPO3-mvc] Mixin support for Extbase 6.0

Claus Due claus at wildside.dk
Fri Jul 27 03:14:07 CEST 2012


Hi Tymek,

Don't take this the wrong way… I appreciate your work and efforts but I fear this is entirely redundant. I have only one vote regarding this, and that is to make PHP 5.4 a requirement and use Traits which can do exactly this.

Why?

Since DI uses Reflection and Reflection recognizes Traits, Traits can also contain DI methods. Traits may override methods as they wish. Traits are not bound to an Interface (but can be used by Interfaces, too!). Adding a Trait can, if I remember the docs correctly, also add an interface to a class.

Traits do not require the use of code generation but still supports Reflection caching etc. Traits will not require TS, nor will they be vulnerable to TS syntax problems or inclusion sequence issues, nor will there be problems in FE/BE due to, for example, multiple root TS templates (which is a known Extbase ConfigurationManager issue, I remind you).

Traits don't care about which extension they belong to, if they do or do not use namespaces or which properties they may contain. Conflicts could only arise in TCA not matching getters/setters. The programmer decides this and does this directly in his source code.

Traits will work the same way in TYPO3 and FLOW3, unless FLOW3 has changed a lot since the last time I looked which is certainly a very likely possibility. Traits will not require special considerations about wether or not subclassing a class will inherit Traits used by the parent. It will. If using Traits there is no confusion about what to expect if overriding a class but intentionally not subclassing the original class.

A very hard punch: Traits will not result in two files containing the same class name, which will likely cause a fatal error or inability to load the expected classes.

And the last, killer argument:

Traits will be recognised by IDEs and other software that reads class files. Please, please, don't choose a solution that will kill these capabilities when there is an alternative that won't.

Traits is by far the better, faster, more reliable, more comfortable, easier, more efficient, less costly, more mature and more developer-friendly solution of the two. Why would anyone not prefer that?

---

As you can see I'm a big fan of Traits and definitely not a fan of a reinvention of this concept, even worse in userland - further bloating an already bloated ObjectManager and in particular the inconsiderate caching implemented herein.

I would like to hear any arguments against using Traits. As far as I can tell, they effectively make any considerations about mixins or multiple inheritance as an Extbase feature completely redundant. The answer will be "Why? when PHP can already do that natively and compatibly?".

Unless I'm wrong?

Cheers,
Claus

On Jul 26, 2012, at 11:43 PM, Tymoteusz Motylewski <t.motylewski at gmail.com> wrote:

> Hey,
> During Extbase sprint in Stuttgart last week, we discussed implementation of mixins in Extbase.
> What are mixins? Basically, they are kind of php "snippets" which can be added to the existing classes. A tipical usecase would be to add additional field to existing model e.g. gender to fe_user.
> 
> I would like to get some feedback about this feature, your expectations and potential use cases. As FLOW3 doesn't have mixins, it's also very important for me to gather opinions about implementation with FLOW3 experts. Especially to agree on configuration structure.
> 
> Initial implementation should be simple - small step, but in the good direction :) Later we can drop some usage restrictions and add functionality.
> So, I would like to hear your opinion on ideal and realistic-"1.0" implementation:
> a). How should mixin support work ideally (this is a direction), how to handle inheritance of mixed classes and overriding mixed classes with DI.
> b). What should be included (what usage restrictions are acceptable) in initial implementation
> 
> Here are some requirements we gathered during sprint:
> 1. Conflicts (between mixins, or between mixin and original class) will not be resolved and will result in error.
> 2. Mixin code will be added to the end of the original class file, and a file with new version of this class will be stored.
> 3. Object Manager has to include file with mixin instead of original file.
> 4. One class can have multiple mixins attached.
> 5. The configuration might look like this: - please see [1]
> 
> Cheers
> Tymek Motylewski
> 
> [1] http://forge.typo3.org/issues/39305
> _______________________________________________
> TYPO3-project-typo3v4mvc mailing list
> TYPO3-project-typo3v4mvc at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-project-typo3v4mvc



More information about the TYPO3-project-typo3v4mvc mailing list