[TYPO3-mvc] Proposal: mixed-ins for extbase

[Helmut Hummel]

Hi,

back to that topic.

On 03.08.10 18:46, Bastian Waidelich wrote:
> 
>>> BTW: we probably need those proxy PHP classes anyways (for high-performance DI). We need to think
>>> about a clean approach here (e.g. you might need different proxies depending on the context)
>>
>> Why proxies? We use an auto-loader so we can load any file we want? [...]
> 
> Right. For DI we might not need proxies - Felix is currently working on 
> a ObjectManager "backport" that would wire up dependencies automatically 
> [1]. Lets see how fast this will be.
> 
> Anyways, for mixins we will need proxies pretty sure - at least until 
> support for traits [2] or mixins [3] is part of the PHP core..

I thought about this and also talked to Sebastian recently.

If we'd use the proxy approach for implementing mixin support in
extbase, we would limit possibilities or maximize complexity.

Consider the following:

class A {}
class B extends A {}

How should we intercept class A with a proxy class adding the mixin
methods and properties? We must then also intercept and rewrite the class B.

It can get worse:
class C extends B {}

Some kind of parser must traverse whole class hirarchies; preformance
good bye.

I had another idea, which Sebastian agreed would be a way to go:

We could store he mixins registry in a global variable like:

$TYPO3_CONF_VARS['EXTCONF']['extbase']['mixins']['Tx_OtherExt_Domain_Model_BaseModel']['your_ext']
= 'EXT:your_ext/classes/Tx_YourExt_Domain_Model_BaseModelMixin.php';

Then modify the extbase autoloader that it looks up registered mixins
for the class that should be loaded.

At this place we could get the contents of the main class file and all
registered mixins, concatenate the contents by removing the class
definitions of the mixins and the closing curly brace of main class and
mixins, writing a new class file at a temporary place and require it.

Voilà we extended the class with new methods and properties of the
mixins. Example:

class A {
  protected $a;
  public function getA() {
    return $this->a;
  }
}
class B extends A {
  protected $b;
  public function getB() {
    return $this->b;
  }

}

class foo mixins A {
  protected $foo;
  public function getFoo() {
    return $this->foo;
  }

}


During the autoloading the file containing claas A is concatenated with
the file containing the mixin like this:

class A {
  protected $a;
  public function getA() {
    return $this->a;
  }
  protected $foo;
  public function getFoo() {
    return $this->foo;
  }
}

Stored to temporary place using the php caching frontend with the file
backend and requiring the concatenated class right away. Because of the
possibility of file caching, the performance of this aproach would be
quite OK I guess. Additionally class B also has access to the new
methods of the mixins.


Advantages:
* Very flexible: One can extend even abstract or static classes.
* Very fast: Due to file cache, parsing needs to be done only once.

Disadvantages:
* The autoloader is probably not the nicest place to have this
functionality (however it would be possible to implement it into an
object manager).

* It will be difficult to have proper error handling, giving nice errors
if the mixin conflicts with already defined methods or properties.

* It is not possible to override methods within a mixin (which might be
a bad idea anyways)

If you think I'm going into the right direction, I'm willing to provide
a prototyped implementation soon.

So please comment.

Regards Helmut