> On Jul 5, 2022, at 5:38 PM, shinji igarashi <s...@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
