Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118242
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
In-Reply-To: <CAH19jWhvuLBT3kZ-u1SPEgwEec=JfALuaiy+Lma9F8WAbqANWw@mail.gmail.com>
Date: Sun, 10 Jul 2022 22:10:07 -0400
Cc: shinji igarashi <sji@sj-i.dev>
Content-Transfer-Encoding: quoted-printable
Message-ID: <59FBF770-ECEC-4004-A039-3C6EB58618F0@newclarity.net>
References: <CAH19jWhvuLBT3kZ-u1SPEgwEec=JfALuaiy+Lma9F8WAbqANWw@mail.gmail.com>
To: internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] [VOTE] Constants in traits
From: mike@newclarity.net (Mike Schinkel)

> On Jul 5, 2022, at 5:38 PM, shinji igarashi <sji@sj-i.dev> wrote:
>=20
> Hello internals,
>=20
> I've started the vote for the Constants in Traits RFC:
> https://wiki.php.net/rfc/constants_in_traits
>=20
> The vote will end on 19. July 2022.
>=20
> Thanks!
>=20
> --
> Shinji Igarashi

The reaction to this RFC has been truly eye-opening to me.  It never =
occurred to me that Traits would be viewed so negatively by some on =
Internals.=20

Personally I have found Traits to be one of the VERY BEST features of =
PHP for a userland developer given their ability to reduce complexity =
and allow for a cleaner code architecture within the applications I have =
worked on. OTOH I have always found Traits to be an incomplete language =
feature whose design gaps I have handled via rigidly standardizing how I =
use them and by incorporating a lot of unfortunate boilerplate.

Though I was surprised at first that some people so strongly dislike =
Traits I then thought more about the incompleteness of Traits and wonder =
if that is not the reason they feel Traits are problematic?  I further =
wonder how their use-cases differ from the ones I have been involved =
with?

Given the three people who spoke strongly against them on this thread =
work heavily with PHP tools that make heavy use of reflection, code =
analysis, and/or work on PHP core I wonder if their dislike for Traits =
have a lot to do Trait-related problems they have when implementing PHP =
core itself, frameworks, ORMs, testing tools, etc. rather than userland =
development?=20

I am in no-way discounting the importance of core or tool development =
but I wonder if they recognized issues in the implementation-of and =
design decisions related-to Traits that most userland developers rarely =
ever see because of their core and/or tool development work?

Further, I wonder if their dislike of Traits is more of an X-Y problem?  =
IOW, that because they have seen issues with Traits they view the =
solution to tamp down on Traits rather than the solution being to fill =
in the design gaps and implementation issues with Traits?

------

So, can those who spoke against Traits please explain more details =
about:

1. How do Traits have "built-in accidental complexity?" =20

2. How does `use TRAIT1, TRAIT2, TRAIT3` semantics result in =
"mind-boggling over-complicated?"

3. What extra compatibility checks are required for Traits?

4. What are the potential error scenarios that are "unnecessary," why =
are they unnecessary, and what alternative could you envision?=20

5. What about the implementation of Traits do you strongly dislike, what =
type of implementation would be better, and could PHP change the =
implementation and still retain backward compatibility?

-----

I pose these questions in hopes to discern among Internals if Traits are =
actually the problem or if instead Traits could be improved to solve the =
concerns states in this tread, which might require some longer-term =
deprecation of some of the problematic aspects of Traits.

-Mike
P.S. I also want to talk about the issues I have with the RFC itself and =
what other things I see that I think are design gaps in Traits, but I =
don't want to create an email to the list with more than one focus.  =
I'll follow up later with those other issues.