Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118226
MIME-Version: 1.0
References: <CAH19jWhvuLBT3kZ-u1SPEgwEec=JfALuaiy+Lma9F8WAbqANWw@mail.gmail.com>
In-Reply-To: <CAH19jWhvuLBT3kZ-u1SPEgwEec=JfALuaiy+Lma9F8WAbqANWw@mail.gmail.com>
Date: Fri, 8 Jul 2022 09:29:07 -0700
Message-ID: <CAMrTa2E27EHQvtB=r0NvNRHH8-bjmexaQH3rsWAfKgO3ObiQtg@mail.gmail.com>
To: shinji igarashi <sji@sj-i.dev>
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007088d705e34db4da"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Constants in traits
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--0000000000007088d705e34db4da
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 5, 2022 at 2:39 PM shinji igarashi <sji@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.

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

--0000000000007088d705e34db4da--