Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101942
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEsg9X2PK1C-COMaz=PF_gYfbSJ8jO2eRhct8GEFPKmqEEMfaA@mail.gmail.com>
References: <CAEsg9X2PK1C-COMaz=PF_gYfbSJ8jO2eRhct8GEFPKmqEEMfaA@mail.gmail.com>
Date: Thu, 1 Mar 2018 01:34:31 +0100
Message-ID: <CADyq6sLB9Gbyr-cMvNy=0AncTq=jBBed5HcE5HGTwt=b1MgPMQ@mail.gmail.com>
To: David Rodrigues <david.proweb@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a11442ae20c620e05664f0671"
Subject: Re: [PHP-DEV] Traits with interfaces
From: ocramius@gmail.com (Marco Pivetta)

--001a11442ae20c620e05664f0671
Content-Type: text/plain; charset="UTF-8"

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.

On 28 Feb 2018 21:58, "David Rodrigues" <david.proweb@gmail.com> wrote:

> 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
>

--001a11442ae20c620e05664f0671--