[policy, no patch] Trait strategy

Problem/Motivation

In light of #1498574: [policy, no patch] Require PHP 5.4 → being approved by Dries, we will have Traits available to us for Drupal 8. Yay! OK, so where do we want to use them?

Remember, traits are *not* an alternative for proper object composition. Their main use is for reducing boilerplate code and providing utility code without relying on inheritance. Crell would describe them as "a cleaner alternative to utility base classes".

It general, traits, like interfaces, should be small and focused. It is *really really easy* to include multiple traits in a single class, and ends up being nicely self-documenting.

Note that traits may not implement an interface; however, a class may implement an interface by using a trait that happens to do so. For example: http://3v4l.org/07EQM

Proposed resolution

Draft policy:

General guidelines

All abstract base classes SHOULD be considered as possible candidates to replace with one or more traits, particularly if they are used primarily for code sharing and not "is a special case of" relationships. (Reason: abstract classes often exist only to provide incomplete partial implementations, which traits do as well but without "stealing" the "is a special case of" relationship.)

Traits SHOULD be single-purpose. That is, ControllerBase should not be unilaterally replaced with ControllerTrait, but the various bits and pieces of ControllerBase MAY be replaced with multiple targeted traits.

Traits used for common application-level dependency injection (like translation) MUST include an override method for easier testing.

Traits used for common application-level dependency injection (like translation) SHOULD use private variables. (This helps enforce the previous point.)

An Interface that implies two or more "this method will be identical for 99% of all implementers" methods SHOULD provide a trait that does so, and SHOULD NOT provide an abstract base class.

Infrastructure-level and domain-level classes (ie, things that we do want to unit test in the majority case) MUST NOT use traits as an alternative to proper dependency injection. ONLY application-level code (controllers, forms, etc.) should do that. (They may still use other traits as appropriate, but not as an alternative to dependency injection.)

Services surfaced in \Drupal are good candidates to consider offering a trait for, but that does not imply that there should be a 1:1 correlation between the two.

Possible candidates for conversion

Proposed application-level traits

Remaining tasks

Agree on standards/policies/guidelines for using Traits.

Make a Coding Standards page under https://drupal.org/coding-standards describing these guidelines, or add it to the existing page on classes/interfaces (https://drupal.org/node/608152)

Agree on which classes to convert to using Traits.

File separate issues to convert those classes to using Traits.

Make sure that api.drupal.org can deal with Traits -- which will involve updates to the Grammar Parser and API module projects.

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Comment 4 days ago →
🇳🇿New Zealand quietone
The discussion here was active 9 years ago. Since then, there have been two comments, one supporting traits for tests and the other opposing this approach. But that last comment was 5 years ago, so it seems there is no interest in pursing the proposal here.

Is there interest in this or should it be closed?

I am setting the status to Postponed (maintainer needs more info). If confirmation that this needs further work is not received, this may be closed after three months.