Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118209
MIME-Version: 1.0
References: <CAH19jWhvuLBT3kZ-u1SPEgwEec=JfALuaiy+Lma9F8WAbqANWw@mail.gmail.com>
 <CADyq6s+Nf7GOyj1gOjt4o5a80B7LcP73Tq3Y3aTG_KGLx0q5vA@mail.gmail.com>
In-Reply-To: <CADyq6s+Nf7GOyj1gOjt4o5a80B7LcP73Tq3Y3aTG_KGLx0q5vA@mail.gmail.com>
Date: Wed, 6 Jul 2022 23:45:34 +0900
Message-ID: <CAH19jWhEDkc7pEqJ88W9DxuFdne6C3_eLuxDSeDfp7qyP4EG-g@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [VOTE] Constants in traits
From: sji@sj-i.dev (shinji igarashi)

Hey Marco,

thanks for giving your reasons!

> traits are pretty much unnecessary in the language.

Perhaps for this RFC it is necessary to first provide use cases for traits =
and
defend themselves before trait constants.
It's understandable that this is a premise that needs to be shared first,
since trait was originally a mechanism designed to replace certain uses of
inheritance, and inheritance itself is an enough controversial feature in
today's PHP world.

This discussion on "how traits should be treated today" is probably an
important point for the community, but I will reply to this in a separate e=
mail,
so I will first consider the other points in this email.

> 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

I did not understand the intent here. I think both traits and classes are
examples of mechanisms to package behavior and data. Why is it
allowed for classes to represent invariants by const, but not for traits?

> 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.

Since the proposed trait constants cannot be overridden in the
composing class, their definition serves as a sort of contract for the
internal implementation of the trait.

> Referencing symbols of the implementing class in a trait is a clear
> mistake (again, an example from the RFC)

I agree with this point.
And avoiding this is one of the main goals of this RFC.

> this expands trait compatibility checks, introducing a number of
> potential error scenarios

I am skeptical of the claim that this is a problem that the introduction of
trait constants itself has.
If there is a situation where this is really a problem, it would be another
problem where members of traits have no choice but to share namespaces with=
in
the composing class, so I think it would be better to solve this with anoth=
er
proposal.
Whether we should solve the name conflict problem with another proposal wil=
l
ultimately come down to the question of how we should deal with traits in t=
he
future, though.

Thanks!

--
Shinji Igarashi

2022=E5=B9=B47=E6=9C=886=E6=97=A5(=E6=B0=B4) 18:46 Marco Pivetta <ocramius@=
gmail.com>:
>
> Hey Shinji,
>
> On Tue, 5 Jul 2022 at 23:39, 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.
>
>
> I voted "NO" on this.
>
> Reasoning:
>
>  * traits are pretty much unnecessary in the language. Since their introd=
uction in PHP 5.4 their usage went from "let's try this out" to "how do I b=
urn 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 se=
parated to clear invariant objects/functions/static methods, instead of bei=
ng put in a trait
>  * a trait does not know the public API of its implementor either, so `se=
lf::SOME_CONSTANT` inside a trait points nowhere sensible, since there is n=
o clear contract on the possible implementations. Referencing symbols of th=
e implementing class in a trait is a clear mistake (again, an example from =
the RFC)
>  * this expands trait compatibility checks, introducing a number of poten=
tial 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 const=
ants 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/
>