Hello everyone! > traits are pretty much unnecessary in the language.
I was writing an email to introduce and defend the trait use cases and it exceeded 10,000 characters, so I decided to post the content on gist and include a summary in this email. Here's my opinion in detail for those interested. https://gist.github.com/sj-i/7981487f879bd9aad8f57a931de1591e I hope it will be used as fodder for future discussions on what traits should be in the future. Also, if anyone has other opinions on use cases or weaknesses of traits, it would be helpful if you could explain them. Here is a summary of the content. IMO, the following are possible valid use cases for traits, and actual use cases may be a combination of several of these. - Provide a default implementation of an interface - Achieve multiple inheritance - Split class implementations between machine-generated and handwritten, etc. - Port code from other languages that have similar mechanisms to trait - Share implementations of classes coincidentally having the same functionality At present and in the future, traits should be used for relatively minor use cases that are not easy to achieve with compositions. Some of these use cases can also be addressed by the introduction of similar features, such as interfaces with default implementations or real multiple inheritance. I am pessimistic about such competing ideas surviving the vote in the PHP RFC process because of the very existence of traits in PHP right now. However, if there is overwhelming agreement that traits should be abandoned while the need for language support for the use cases itself is agreed, then this will lead to a future where such alternatives are introduced. I would be OK with such a future if it is promising, but if you do not have such a strong foresight, please support the modification of the existing trait to make it a little more manageable, as a backing up plan. Thanks! -- Shinji Igarashi 2022年7月6日(水) 18:46 Marco Pivetta <ocram...@gmail.com>: > > Hey Shinji, > > On Tue, 5 Jul 2022 at 23:39, 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. > > > I voted "NO" on this. > > Reasoning: > > * traits are pretty much unnecessary in the language. Since their > introduction in PHP 5.4 their usage went from "let's try this out" to "how do > I burn this with fire?". I don't want traits to expand in scope: they already > do enough damage with their built-in accidental complexity. > * invariants shared by trait (example in the RFC) are generally to be > separated to clear invariant objects/functions/static methods, instead of > being put in a trait > * a trait does not know the public API of its implementor either, so > `self::SOME_CONSTANT` inside a trait points nowhere sensible, since there is > no clear contract on the possible implementations. Referencing symbols of the > implementing class in a trait is a clear mistake (again, an example from the > RFC) > * this expands trait compatibility checks, introducing a number of potential > error scenarios that are unnecessary (due to the already mind-boggling > over-complicated `use TRAIT1, TRAIT2, TRAIT3` semantics) > > In practice, while this may make on surface because you can declare constants > everywhere, declaring more stuff on traits is problematic. > > From a technical and detail PoV, your RFC is well written and implemented: it > just solves a problem that doesn't/shouldn't need solving. > > Greets, > > Marco Pivetta > > https://twitter.com/Ocramius > > https://ocramius.github.io/ > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
