Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118240
MIME-Version: 1.0
References: <CAH19jWhvuLBT3kZ-u1SPEgwEec=JfALuaiy+Lma9F8WAbqANWw@mail.gmail.com>
 <CADyq6s+Nf7GOyj1gOjt4o5a80B7LcP73Tq3Y3aTG_KGLx0q5vA@mail.gmail.com>
In-Reply-To: <CADyq6s+Nf7GOyj1gOjt4o5a80B7LcP73Tq3Y3aTG_KGLx0q5vA@mail.gmail.com>
Date: Mon, 11 Jul 2022 05:57:19 +0900
Message-ID: <CAH19jWi995TAUC+5oJD+GDJaHa1May-Dukpy2qsA+e=s6hhWXQ@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [VOTE] Constants in traits
From: sji@sj-i.dev (shinji igarashi)

Hello everyone!

> traits are pretty much unnecessary in the language.

I was writing an email to introduce and defend the trait use cases and it
exceeded 10,000 characters, so I decided to post the content on gist and
include a summary in this email.

Here's my opinion in detail for those interested.
https://gist.github.com/sj-i/7981487f879bd9aad8f57a931de1591e

I hope it will be used as fodder for future discussions on what traits shou=
ld
be in the future.

Also, if anyone has other opinions on use cases or weaknesses of traits,
it would be helpful if you could explain them.

Here is a summary of the content.

IMO, the following are possible valid use cases for traits, and actual use
cases may be a combination of several of these.

- Provide a default implementation of an interface
- Achieve multiple inheritance
- Split class implementations between machine-generated and handwritten, et=
c.
- Port code from other languages that have similar mechanisms to trait
- Share implementations of classes coincidentally having the same functiona=
lity

At present and in the future, traits should be used for relatively minor us=
e
cases that are not easy to achieve with compositions.

Some of these use cases can also be addressed by the introduction of simila=
r
features, such as interfaces with default implementations or real multiple
inheritance. I am pessimistic about such competing ideas surviving the vote=
 in
the PHP RFC process because of the very existence of traits in PHP right no=
w.

However, if there is overwhelming agreement that traits should be abandoned
while the need for language support for the use cases itself is agreed, the=
n
this will lead to a future where such alternatives are introduced.

I would be OK with such a future if it is promising, but if you do not have
such a strong foresight, please support the modification of the existing tr=
ait
to make it a little more manageable, as a backing up plan.

Thanks!

--
Shinji Igarashi

2022=E5=B9=B47=E6=9C=886=E6=97=A5(=E6=B0=B4) 18:46 Marco Pivetta <ocramius@=
gmail.com>:
>
> Hey Shinji,
>
> On Tue, 5 Jul 2022 at 23:39, shinji igarashi <sji@sj-i.dev> wrote:
>>
>> Hello internals,
>>
>> I've started the vote for the Constants in Traits RFC:
>> https://wiki.php.net/rfc/constants_in_traits
>>
>> The vote will end on 19. July 2022.
>
>
> I voted "NO" on this.
>
> Reasoning:
>
>  * traits are pretty much unnecessary in the language. Since their introd=
uction in PHP 5.4 their usage went from "let's try this out" to "how do I b=
urn this with fire?". I don't want traits to expand in scope: they already =
do enough damage with their built-in accidental complexity.
>  * invariants shared by trait (example in the RFC) are generally to be se=
parated to clear invariant objects/functions/static methods, instead of bei=
ng put in a trait
>  * a trait does not know the public API of its implementor either, so `se=
lf::SOME_CONSTANT` inside a trait points nowhere sensible, since there is n=
o clear contract on the possible implementations. Referencing symbols of th=
e implementing class in a trait is a clear mistake (again, an example from =
the RFC)
>  * this expands trait compatibility checks, introducing a number of poten=
tial error scenarios that are unnecessary (due to the already mind-boggling=
 over-complicated `use TRAIT1, TRAIT2, TRAIT3` semantics)
>
> In practice, while this may make on surface because you can declare const=
ants everywhere, declaring more stuff on traits is problematic.
>
> From a technical and detail PoV, your RFC is well written and implemented=
: it just solves a problem that doesn't/shouldn't need solving.
>
> Greets,
>
> Marco Pivetta
>
> https://twitter.com/Ocramius
>
> https://ocramius.github.io/
>