Re: [RFC] [VOTE] Constants in traits
| From: | Björn Larsson via internals | Date: | Sun, 10 Jul 2022 12:51:01 +0000 |
| Subject: | Re: [RFC] [VOTE] Constants in traits | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-118235@lists.php.net to get a copy of this message | ||
Den 2022-07-08 kl. 18:29, skrev Jordan LeDoux:
On Tue, Jul 5, 2022 at 2:39 PM shinji igarashi <sji@sj-i.dev> wrote:from that perspective I think one should do it as good as possible. Even if one thinks that this is a bad feature not to be expanded, why not try to make it work better? So, I hope this RFC passes! Regards //Björn LHello 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 IgarashiI 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. 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. Jordan I think it's quite unlikely to deprecate such a rather big feature and