> On 11 Jul 2022, at 09:10, Mike Schinkel <m...@newclarity.net> wrote: > >> 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 >
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.
