[TYPO3-mvc] Mixin support for Extbase 6.0

[Claus Due]

Hi Tymek,

I see your point. However, I still think the main reason for needing mixins is poor design.

What should be done is "programming to the interface, not the implementation", i.e. the Strategy pattern. We're trying to solve a problem with inheritance that, with regular PHP, is unsolvable. This should tell us something, namely that what we're thinking about right now could turn out to be both a can of worms, as well as a bad pattern (which it is, at least for PHP - Ruby is another story).

But I also recognize that it is an extreme task having to adapt the framework if somebody somewhere suddenly requires a new capability. Not an easy decision surely.

I do however have huge worries as a programmer. I would like to know that my Interfaces are being respected completely and that my implementations are as they are (but can be replaced), because this would limit the number of possible causes for errors over which I would have no control whatsoever.

An example situation:

---

Say I've defined a class which implements a couple of interfaces. Now, TYPO3 adds some mixins to my class which change a vital method - however, the method still respects the interface but does not do what it is supposed to do any longer. The person who created the mixin may not realize what he has done and the mixin handler would be none the wiser. Compare this to a situation where the implementation had been replaced. The class name of the offending implementation would be reported clearly.

Now a user experiences this bug with this mixed in implementation, this mutant thing that is part code, part insidious horror.

The reported class name and even the method will all come from MY code but the error will be caused by someone else's code and must be fixed by that someone. I would not be able to take responsibility for identifying or even fixing these problems and the user might not know where to direct his problem, nor would he be capable of finding this out unless he was very familiar with the mixin logic.

---

I would not like that situation one tiny bit, nor would my user like it, nor would the third party programmer who causes problems but was not told that he is causing problems because very few people would be able to tell. Having mixins in a language that does not support mixins is a hack and a "black box" in which things can go horribly wrong. Remember the good old XCLASS days? I do. And shiver.

I have to vote against it still, sorry. And at the same time strongly advise people to…

* Program always to the interface, NOT the implementation.
* Allow specific implementations to be mapped to Interfaces, as they are now.
* Let it be each developer's responsibility to make a proper inheritance tree or manually copy needed methods.
* Use SignalSlots whenever this makes sense.
* Request that other programmers add these capabilities knowingly to their code rather than make this decision for all of them.
* If possible, submit change requests that add what you need.
* Remember that your change suggestions often are good inspiration for others. Don't keep them a secret.

This will keep things transparent for everyone involved. Your IDE will be OK with it as well. It will only hinder performance in specific places such as SignalSlot dispatching instead of on a global scale. You can predict the result of everything that goes on and locating the source of an erroneous piece of code remains (relatively) easy.

I really do fear mixins. With good reason, but still willing to listen to counter arguments or use cases that just say "no other way to do this other than re-inventing Ruby mixins as a severe hack for Extbase". I'll do my best to keep an open mind.

Do you (or perhaps someone reading this) have such as use case or is this still just academic?


Cheers - and have a nice weekend,
Claus


On Jul 27, 2012, at 10:08 PM, Tymoteusz Motylewski <t.motylewski at gmail.com> wrote:

> Hi Claus,
> Thank you for your valuable insight!
> Sorry for not being clear in my previous post. I agree with you that using traits is a way to go, no argument here.  :)
> 
> But the problem I'm trying to solve is slightly different.
> I was thinking about "opening" existing class for modification. Then the modified class (with mixins) would be available everywhere in the system under the original name.
> 
> In this case, traits are very handy (for all reasons you highlighted), but do not solve the problem. You still have to modify source of the class by applying traits or mixins.
> 
> Of course, as soon as PHP 5.4 is required by TYPO3 we can use traits instead of simple snippets under the hood.
> 
> Have a nice evening
> Cheers
> Tymek
> 
> 
> 
> 
> W dniu 2012-07-27 03:14, Claus Due pisze:
>> 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
>> 
> _______________________________________________
> TYPO3-project-typo3v4mvc mailing list
> TYPO3-project-typo3v4mvc at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-project-typo3v4mvc