Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116836
MIME-Version: 1.0
References: <1641335738.195767637@f174.i.mail.ru> <CA+p1Faa_BAv-DdR7D4Jee2XwNNmVQmmkDf_T_Z_4nAYxWtQPqA@mail.gmail.com>
 <CAPKYkKy4AtAheYTyS9zn4Bz14x1Eq15amjCcPEBFtvML0cUxGQ@mail.gmail.com>
 <5a4aebf8-e592-4517-8930-d18b112ef1fd@www.fastmail.com> <5a99809d-afda-546c-5a11-a4f0f821aa37@korulczyk.pl>
 <A91D0AC0-D646-4C62-9FF3-EDE8279E43B7@gmail.com> <CAPKYkKyanQfct9SdLGyed76JHYfjr_Pmqn6LczBLWkML2nu_wA@mail.gmail.com>
 <C3E955EC-B511-4CE9-B9DF-0B801CF01631@gmail.com> <CAAwdEzDNBdBPLqN4gjzWMxGMPs88WV=fXKNu=5LBoXuhj3UVLw@mail.gmail.com>
In-Reply-To: <CAAwdEzDNBdBPLqN4gjzWMxGMPs88WV=fXKNu=5LBoXuhj3UVLw@mail.gmail.com>
Date: Thu, 6 Jan 2022 13:03:04 -0500
Message-ID: <CAPKYkKwB0rP-yD1kUWvyPcJYRO1-wRTaQATHug4zcZmKsutpeA@mail.gmail.com>
To: =?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?= <drealecs@gmail.com>
Cc: Rowan Tommins <rowan.collins@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000165c7405d4edaf17"
Subject: Re: [PHP-DEV] RFC: Trait expects interface
From: chasepeeler@gmail.com (Chase Peeler)

--000000000000165c7405d4edaf17
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 6, 2022 at 12:37 PM Alexandru P=C4=83tr=C4=83nescu <drealecs@gm=
ail.com>
wrote:

> On Thu, Jan 6, 2022 at 7:12 PM Rowan Tommins <rowan.collins@gmail.com>
> wrote:
>
> >
> > But some comments seem to be hinting at some *separate* advantage, to d=
o
> > with "correct usage" of the trait, which I haven't grasped. It's possib=
le
> > that the mention of static analysis relates to that in some way, and I'=
m
> > just completely missing the point.
> >
>
> Yes, traits are a language construct that has in general more negative
> implications than positive so it's good to keep an eye on their usage.
> One of the okish usages is to define some implementation for an interface
> that classes can use.
> Limiting that trait to be used only by classes implementing the interface
> is seen as a restriction placed on the trait that would not allow it to b=
e
> used in other places when it might have a negative impact.
>
>
And that's what I don't like about this. I'm totally OK with allowing
developers to do things the "wrong" way. It might end up that it's the
"right" way for their use-case.


> Just as a note, on the composition vs inheritance line, I see traits
> somewhere in the middle.
> I'll always prefer to go for full composition, even if that means a bit
> more boilerplate. The implementation can very well sit in a class and hav=
e
> it as a dependency of the class that needs it.
>
> Alex
>

>  but that wouldn't be any *easier* for the tool, and in fact would be
extra logic for them to implement, so it seems an odd thing to bring up.

I think most people see the tools as black boxes to make THEIR lives
easier. They aren't concerned about whether it's added complexity to the
tool itself. If PhpStorm allows me to reference
$this->someMethodFromAnInterface() without defining
someMethodFromAnInterface() as an abstract method in the trait because I
include "expects <interface>", then that means things are "simpler" for me
as a developer. I don't really think this makes things that much simpler
though.

--=20
Chase Peeler
chasepeeler@gmail.com

--000000000000165c7405d4edaf17--