Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118243
Message-ID: <5E9AA0E3-1162-429C-88BA-BCC7811CB588@koalephant.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_94B7AA42-D263-4DC5-B3D3-4C7015E8E9FA"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Date: Mon, 11 Jul 2022 12:17:19 +0700
In-Reply-To: <59FBF770-ECEC-4004-A039-3C6EB58618F0@newclarity.net>
Cc: shinji igarashi <sji@sj-i.dev>,
 Mike Schinkel <mike@newclarity.net>
To: internals <internals@lists.php.net>
References: <CAH19jWhvuLBT3kZ-u1SPEgwEec=JfALuaiy+Lma9F8WAbqANWw@mail.gmail.com>
 <59FBF770-ECEC-4004-A039-3C6EB58618F0@newclarity.net>
Subject: Re: [PHP-DEV] [RFC] [VOTE] Constants in traits
From: php-lists@koalephant.com (Stephen Reay)

--Apple-Mail=_94B7AA42-D263-4DC5-B3D3-4C7015E8E9FA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 11 Jul 2022, at 09:10, Mike Schinkel <mike@newclarity.net> wrote:
>=20
>> 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
>=20
> 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
>=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.
>=20
> 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?
>=20
> 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
>=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?
>=20
> 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?
>=20
> ------
>=20
> So, can those who spoke against Traits please explain more details =
about:
>=20
> 1. How do Traits have "built-in accidental complexity?" =20
>=20
> 2. How does `use TRAIT1, TRAIT2, TRAIT3` semantics result in =
"mind-boggling over-complicated?"
>=20
> 3. What extra compatibility checks are required for Traits?
>=20
> 4. What are the potential error scenarios that are "unnecessary," why =
are they unnecessary, and what alternative could you envision?=20
>=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?
>=20
> -----
>=20
> 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.
>=20
> -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.
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>=20


I hadn=E2=80=99t planned to get involved in this discussion - my name is =
only on the RFC because Shinji very graciously left it there when he =
took the skeleton of a proposal I=E2=80=99d written a while ago, and =
completed it in ways I never could have. So first off: thank you again =
Shinji for putting the effort in to bring this RFC to a vote. I very =
much appreciate all the effort you put into it.

For context, my work with PHP is split, between application development, =
and library development - so for some of it I=E2=80=99m trying to make =
sure the code is re-usable without having to jump through too many hoops =
(library dev), and for some of it I=E2=80=99m trying to re-use provided =
code, without having to jump through too many hoops (app dev).

I think one of the best descriptions I=E2=80=99ve seen about how traits =
**could** be used, is from an article =
(https://www.garfieldtech.com/blog/beyond-abstract =
<https://www.garfieldtech.com/blog/beyond-abstract>) Larry Garfield =
wrote just a couple of years after traits had been introduced. Larry =
presents the view that with the advent of traits in php, abstract =
classes could (should) be considered vestigial.

Having worked on library-style reusable code using abstract classes to =
provide extendable behaviour since around 2009, I really do like this =
approach, and I=E2=80=99d like to use traits a lot more like this.  But =
looking at numerous cases of existing abstract classes in my own work, =
even with all the other improvements in the language since 5.4, =
there=E2=80=99s still a single missing feature that makes "traits =
instead of abstract classes=E2=80=9D a worse/nonviable option: =
constants.



Thanks again to Shinji, and to those who have voted yes so far.


--Apple-Mail=_94B7AA42-D263-4DC5-B3D3-4C7015E8E9FA--