Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118235 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 26141 invoked from network); 10 Jul 2022 10:57:01 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 10 Jul 2022 10:57:01 -0000 To: internals@lists.php.net,Jordan LeDoux , Shinji Igarashi Message-ID: Date: Sun, 10 Jul 2022 14:51:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Content-Language: en-GB References: Reply-To: =?UTF-8?Q?Bj=c3=b6rn_Larsson?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 84.216.97.240 Subject: Re: [PHP-DEV] [RFC] [VOTE] Constants in traits From: internals@lists.php.net ("Björn Larsson via internals") Den 2022-07-08 kl. 18:29, skrev Jordan LeDoux: > On Tue, Jul 5, 2022 at 2:39 PM shinji igarashi 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. > > 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 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 L