What is the benefit to use trait over inheritance in this cases?
Is it more readable? or is it more efficient?

What is the benefit for us or for the symfony's users to deprecate the class ContainerAware and force them to use the trait?

@jeremy-derusse As I said in the description, with interface+trait, you keep your inheritance free, you will able now to inherit from a class with a real benefit. There is no multiple inheritance in PHP, so we should use it only if really needed.

From the doc :

Traits are a mechanism for code reuse in single inheritance languages such as PHP. A Trait is intended to reduce some limitations of single inheritance by enabling a developer to reuse sets of methods freely in several independent classes living in different class hierarchies. The semantics of the combination of Traits and classes is defined in a way which reduces complexity, and avoids the typical problems associated with multiple inheritance and Mixins. [...] It is an addition to traditional inheritance and enables horizontal composition of behavior; that is, the application of class members without requiring inheritance.

Inheritance provides no more and I think It's actually done in this way because traits doesn't exists in 5.3 otherwise they would have been used.

👍 for me :)

Actually, as a developer, I'm free to use the trait if I want to extends another class. My question is, what is the benefit for me, if you remove the class ContainerAware and to force me to always use the trait?

Hm, I'm actually wondering what is the benefit of using the ContainerAwareTrait for Symfony's internal classes.

@xabbuh in case of refactoring, if we will need to add an inheritance, we won't be blocked.

@jeremy-derusse It will allow you, later, the possibility to add inheritance, you won't be blocked. I don't understand the benefit to use abstract class instead of trait/interface for you?

this is a good idea. containeraware has nothing todo with inheritance. i am 👍

@blanchonvincent Can you finish this one? 👍

@fabpot yep, I'll do that this week end

I would suggest to also make Symfony\Bundle\FrameworkBundle\Controller a trait that uses the ContainerAwareTrait. We already made it abstract in 3.0. But at the end it only offers helper methods that are better suited as a trait. There is not such thing as "a controller" in a inheritance tree. Controllers are just callables.

@Tobion I like your idea about to also make Symfony\Bundle\FrameworkBundle\Controller a trait 👍
I'm waiting for additional feedbacks about this point

If we removed the ContainerAware class in Symfony 3.0, we would need to deprecate it in Symfony 2.8. There's probably a lot of code out there that uses this class.

@xabbuh I agree but according to @fabpot "I don't see the need to deprecated this class, even if we introduce the trait.". So maybe we have to keep both of them?

See #12595 (comment) where we agreed to deprecate the class. Deprecation means, please open a PR against 2.8 to just add the deprecation logic (trigger_error) for this class and tell people to use the Trait if they are on PHP >= 5.5. If they use a lower php version they would need to live the deprecation message.

Edit: We want to deprecate it in 3.0 not in 2.8 (which makes more sense). So it means, we should not remove the class here, but only add the deprecation message.

Status: Needs Work

@Tobion what kind of message would you like? "Deprecated since version 3.0, to be removed in ??"

@Tobion why not deprecate it in 2.8?

@blanchonvincent depends on the decision of deprecation in 2.8 or 3.0, but:

The ContainerAware class is deprecated since version 2.8 and will be removed in 3.0. Use ContainerAwareTrait instead.

The ContainerAware class is deprecated since version 3.0 and will be removed in 4.0. Use ContainerAwareTrait instead.

@wouterj as I wrote above, there would not be a clean upgrade path in 2.8 as the trait cannot be used for PHP < 5.5. And the amount of people affected is maybe not justified in 2.8

@Tobion as Symfony 3 requires PHP 5.5.9, people already need to run Symfony 2.8 on PHP 5.5 for a clean upgrade path (or is this not considered as part of the upgrade path?).

@wouterj People using 2.8 don't need php 5.5. And if they want to get rid of all deprecation messages to be compatible with 3.0 in the future they can also do so on PHP 5.3. But with the ContainerAware class they would have a problem as the replacement wouldn't be available to them. So they would basically need to reimplement this class in their own code to get rid of the deprecation.

BTW, shouldn't we trigger a deprecated error when the version of php is under 5.5 ?

@blanchonvincent do you have time to finish this PR? It needs a rebase and please deprecate ContainerAware class instead of removing it. Deprecation is done by adding a @trigger_error to the file. For examples see other occurences of those deprecations.

Replaced by #16411

@Tobion sorry mate, I am on vacation