> On Jul 8, 2022, at 12:29 PM, Jordan LeDoux <jordan.led...@gmail.com> wrote: > > On Tue, Jul 5, 2022 at 2:39 PM shinji igarashi <s...@sj-i.dev > <mailto: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 >> >> > I don't have a vote, but I wanted to address this concern about the > "usefulness" of traits, since the *voting* stage is rather the wrong place > to bring up the idea that the existence of the feature itself is a > negative. > > In my view, the "correct" way to use traits is for them to be entirely > self-contained. That is, if you can put the trait in *any* class, and have > that trait work as intended *even if* it makes no semantic sense to do so, > then it's a good trait. This is currently somewhat difficult to do in > certain situations. Some of the things the trait may need must live outside > the trait, such as constants. This fact promotes further problematic usage > of the feature. > > Requiring something like class constants to be external to the trait > *forces* the kind of trait designs that they have complained about. Voting > "no" because you want to see the feature removed instead is > counter-productive to the process of improving the language itself if the > RFC in question helps correct an oversight of the original feature design > as stated by the original implementer of this feature and helps to promote > more non-problematic usage of the feature.
+1 > > I don't know how else to view that position except for wanting to keep > design flaws in a feature so that you have additional arguments in the > future to remove it. > That seems to be a very plausible analysis... -Mike
