Re: [RFC] [VOTE] Constants in traits

> On 11 Jul 2022, at 09:10, Mike Schinkel <mike@newclarity.net> wrote: > >> On Jul 5, 2022, at 5:38 PM, 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. >> >> Thanks! >> >> -- >> 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. > > 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? > > 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?" > > 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? > > 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. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > I hadn’t 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’d 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’m 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’m trying to re-use provided code, without having to jump through too many hoops (app dev). I think one of the best descriptions I’ve 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’d 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’s still a single missing feature that makes "traits instead of abstract classes” a worse/nonviable option: constants. Thanks again to Shinji, and to those who have voted yes so far.