don't use traits

Yes, in general, yes.
Composition is great, and I use it most of the time.
I still do have some cases where I think that base classes (with
private properties) are justified, and then some cases where either
traits or multiple inheritance would be justified.
We could agree to set this debate aside, and focus on the original
proposal, assuming it is for those people who have a good reason to
use traits.
But I have a feeling that this part of the discussion ("traits are
bad") isn't over. I will get back to it further below.

due to the previous point, inheriting a type from a trait becomes a dangerous BC boundary, easily broken by consumers of the trait when consumers alias or when the trait implementor adds a new interface implementation

Yes.
On the other hand, many traits out there really try to comply with an
existing interface, and are meant as a replacement for additional base
classes.
The renaming is technically possible, but how often does it occur in reality?

So what about this modified proposal:

• A trait can "promise" to comply with an interface. We could use the
  "implements" keyword for this, but maybe we should rather use
  something else.
• Using the trait in a class does NOT automatically add that interface
  to the class.

I personally don't have a strong desire for this functionality. But at
least this would circumvent the problems you pointed out.

In my personal experience, in all the cases where I did use traits, I
would have rather used multiple inheritance.
Or let's say: In many cases where I did use traits, or base classes, I
did later find a better solution with composition.

A good base class, for me, has

• private properties
• abstract protected methods
• possibly final public methods

In which cases would I use (single) base classes instead of composition?

• If composition would require awkward one-off interfaces.
• If the to-be-implemented methods have parameter constraints that
  cannot be expressed in the signature.

E.g. a base class could implement a public method, do some sanity
checks and preparation on the parameters, then call the abstract
protected method with the processed parameters.

In which cases would I use multiple base classes instead of
composition or single base classes?

• If I want to provide an object with a rich verbose interface to a
  consumer, possibly extending multiple smaller interfaces.
  (- If I am implementing someone else's interface, which happens to
  have more methods than I want to fit in one class.)

Base classes allow to implement partial functionality in isolated
(encapsulated) pockets of an object.
Often each of these pockets is nothing more than a decorator of the
partial interface, and the actual functionality happens in the
injected object.
I would prefer to implement those decorator pockets separately and
then extend them one by one. But this is not possible, because we
don't have multiple inheritance in PHP.

Traits are quite useless for this purpose. They encapsulate nothing.
Therefore I don't like them.

Sometimes if I started with the assumption that I want to provide a
rich one-object interface at least in some places in the architecture,
I later regret it, and split it up again.
But I do think that some cases are justified.

This cannot work for a number of reasons:

• a trait is not a type, and does not practically exist at runtime
• trait defined API can be imported with changed/aliased names, breaking
  therefore the contact defined in the interface
• due to the previous point, inheriting a type from a trait becomes a
  dangerous BC boundary, easily broken by consumers of the trait when
  consumers alias or when the trait implementor adds a new interface
  implementation

My general suggestions:

• don't use traits
• don't use traits
• also, don't use traits
• remember to not use traits
• traits: don't
• things you shouldn't use on Betelgeuse and other systems: traits

Besides jokes, inheriting signatures together with implementations
(inheritance, abstract types) is less and less endorsed in the PHP
ecosystem, as it just increases coupling by a huge lot. At least from my
own experience, things are finally moving towards more composition over
inheritance.

Why traits doesn't supports interfaces (via implements) like classes does?

It could be useful when trait implements part of abstract functions from
interface, then the class that uses this traits should implements the
another part.

It could turn it possible (pseudo-code):

interface VisibilityControlContract

• public function isVisible(): bool;

trait VisibilityControlTrait implements VisibilityControlContract

• public function isVisible(): bool { ... }

class UserModel (not need implements VisibilityControlContract directly)

• uses VisibilityControlTrait;

var_dump(new UserModel instanceof VisibilityControlContract); // true

The disvantages that I can see with that is that without an IDE I could not
identify easily if interface was implemented by some trait. But it too
happen when I do implements an abstract class that implements some
interface.

--
David Rodrigues

Hi all,

• trait defined API can be imported with changed/aliased names, breaking
  therefore the contact defined in the interface

This isn't actually true, because trait method aliases create an extra
copy of the pasted method, rather than actually renaming it. See example
at the end of this e-mail for a demonstration.

I'm not sure why this is; the original traits RFC
[https://wiki.php.net/rfc/horizontalreuse#renaming] says that it is
because of "the dynamic nature of PHP", but the example it gives doesn't
actually show anything breaking.

What can break an interface's contract is changing the visibility of
the pasted method using "as protected" or "as private". This would need
to be captured somehow while composing the class, probably producing a
compile-time error, just as an explicit "implements" declaration would.

While looking for the above RFC, I came across this draft by Kevin
Gessner from 2 years ago for exactly the feature discussed here:
https://wiki.php.net/rfc/traits-with-interfaces It includes references
to potential uses of this feature, and equivalents in other languages.

This appears to be the discussion in the archives, to avoid us repeating
ourselves: https://marc.info/?t=145571923500003&r=1&w=2 and
https://marc.info/?t=145573610000001&r=1&w=2

Appendix: Example of a trait providing implementation for an interface,
even though the method was aliased:

https://3v4l.org/DMAoY

interface Bobbable {
    public function bob();
}
trait Bobber {
    public function bob() {
        echo "Bobbity";
    }
}
class Bibble implements Bobbable {
    use Bobber { bob as bib; }
}
$b = new Bibble;
$b->bob();
$b->bib();

Regards,

--
Rowan Collins
[IMSoP]