[RFC] [VOTE] Constants in traits

Marco Pivetta

4 years ago

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
introduction in PHP 5.4 their usage went from "let's try this out" to "how
do I burn 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
separated to clear invariant objects/functions/static methods, instead of
being put in a trait
* 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. Referencing symbols
of the implementing class in a trait is a clear mistake (again, an example
from the RFC)
* this expands trait compatibility checks, introducing a number of
potential 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
constants 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/

Larry Garfield

4 years ago

On Wed, Jul 6, 2022, at 4:45 AM, Marco Pivetta wrote:

> 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
> introduction in PHP 5.4 their usage went from "let's try this out" to "how
> do I burn this with fire?". I don't want traits to expand in scope: they
> already do enough damage with their built-in accidental complexity.

Point of order: This is a subjective position not universally held.  Traits are certainly misusable, but so is literally everything.  If used judiciously, I have found them useful.  Certainly they are better than abstract classes in many cases.

You may not like them, but that doesn't make them intrinsically harmful to the language by their existence.  They are not.

--Larry Garfield

Marco Pivetta

4 years ago

On Wed, 6 Jul 2022 at 16:17, Larry Garfield <larry@garfieldtech.com> wrote:

> On Wed, Jul 6, 2022, at 4:45 AM, Marco Pivetta wrote:
> > 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
> > introduction in PHP 5.4 their usage went from "let's try this out" to
> "how
> > do I burn this with fire?". I don't want traits to expand in scope: they
> > already do enough damage with their built-in accidental complexity.
>
> Point of order: This is a subjective position not universally held.
> Traits are certainly misusable, but so is literally everything.  If used
> judiciously, I have found them useful.  Certainly they are better than
> abstract classes in many cases.
>
> You may not like them, but that doesn't make them intrinsically harmful to
> the language by their existence.  They are not.
>

Certainly, but unnecessary features are bloat, and bloat is a clear
negative.
A feature's value must outweigh its carried maintenance and cognitive
effort in order to justify its existence.

As someone who worked a lot with analyzing traits (especially in reflection
context), traits don't respect that requirement, **BY FAR**.

Also, the idea of the RFC process here is that voters bring in their own
requirements: my requirement is as subjective as yours.

Greets,

Marco Pivetta

https://twitter.com/Ocramius

https://ocramius.github.io/

Larry Garfield

4 years ago

On Wed, Jul 6, 2022, at 9:23 AM, Marco Pivetta wrote:

> Also, the idea of the RFC process here is that voters bring in their own
> requirements: my requirement is as subjective as yours.

Sure.  You're welcome to vote against this or any RFC for whatever reasons you have.  What I was objecting to was the assertion that traits were generally understood by all as evil, when that is simply not the case at all.

--Larry Garfield

Marco Pivetta

4 years ago

On Wed, 6 Jul 2022 at 16:26, Larry Garfield <larry@garfieldtech.com> wrote:

>  simply not the case at all.
>

It's neither "simply" nor "not the case at all".

They are the spaghettiest concept in the language after autoloading symbol
resolution shenanigans, so be my guest in writing a blogpost that puts
measurable value on traits.

I measured negative value over here, over years.

Marco Pivetta

https://twitter.com/Ocramius

https://ocramius.github.io/

shinji igarashi

4 years ago

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 email,
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 within
the composing class, so I think it would be better to solve this with another
proposal.
Whether we should solve the name conflict problem with another proposal will
ultimately come down to the question of how we should deal with traits in the
future, though.

Thanks!

--
Shinji Igarashi

2022年7月6日(水) 18:46 Marco Pivetta <ocramius@gmail.com>:

Sebastian Bergmann

4 years ago

On 7/6/22 11:45, Marco Pivetta wrote:

> I don't want traits to expand in scope

I voted NO for this exact reason.

> 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.

Agreed!

shinji igarashi

4 years ago

Hello everyone!

> traits are pretty much unnecessary in the language.

I was writing an email to introduce and defend the trait use cases and it
exceeded 10,000 characters, so I decided to post the content on gist and
include a summary in this email.

Here's my opinion in detail for those interested.
https://gist.github.com/sj-i/7981487f879bd9aad8f57a931de1591e

I hope it will be used as fodder for future discussions on what traits should
be in the future.

Also, if anyone has other opinions on use cases or weaknesses of traits,
it would be helpful if you could explain them.

Here is a summary of the content.

IMO, the following are possible valid use cases for traits, and actual use
cases may be a combination of several of these.

- Provide a default implementation of an interface
- Achieve multiple inheritance
- Split class implementations between machine-generated and handwritten, etc.
- Port code from other languages that have similar mechanisms to trait
- Share implementations of classes coincidentally having the same functionality

At present and in the future, traits should be used for relatively minor use
cases that are not easy to achieve with compositions.

Some of these use cases can also be addressed by the introduction of similar
features, such as interfaces with default implementations or real multiple
inheritance. I am pessimistic about such competing ideas surviving the vote in
the PHP RFC process because of the very existence of traits in PHP right now.

However, if there is overwhelming agreement that traits should be abandoned
while the need for language support for the use cases itself is agreed, then
this will lead to a future where such alternatives are introduced.

I would be OK with such a future if it is promising, but if you do not have
such a strong foresight, please support the modification of the existing trait
to make it a little more manageable, as a backing up plan.

Thanks!

--
Shinji Igarashi

2022年7月6日(水) 18:46 Marco Pivetta <ocramius@gmail.com>:

Jordan LeDoux

4 years ago

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

Mike Schinkel

4 years ago

> On Jul 8, 2022, at 12:29 PM, Jordan LeDoux <jordan.ledoux@gmail.com> wrote:
>
> On Tue, Jul 5, 2022 at 2:39 PM shinji igarashi <sji@sj-i.dev <mailto: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.

+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

Unnamed Person

4 years ago

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:
>
>> 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

Rowan Collins

4 years ago

On 10/07/2022 13:51, Björn Larsson via internals wrote:

> 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!

I agree.

Having sat down and read through the RFC, it is extremely conservative
in its scope, and presents a clear case that it will fix a source of
bugs in things that people can already do, i.e. reference constants
inside a trait definition.

It seems very unlikely that this change will make people suddenly use
traits in more "wrong" places, nor prevent any alternative horizontal
reuse / composition aid features being added in future.

Regards,

--
Rowan Tommins
[IMSoP]

Nikita Popov

4 years ago

On Sun, Jul 10, 2022 at 3:46 PM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> On 10/07/2022 13:51, Björn Larsson via internals wrote:
> > 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!
>
>
> I agree.
>
> Having sat down and read through the RFC, it is extremely conservative
> in its scope, and presents a clear case that it will fix a source of
> bugs in things that people can already do, i.e. reference constants
> inside a trait definition.
>
> It seems very unlikely that this change will make people suddenly use
> traits in more "wrong" places, nor prevent any alternative horizontal
> reuse / composition aid features being added in future.
>

I tend to agree. While I strongly dislike traits (or at least our
implementation of them), they're here to stay and we should make them less
bad where we can. Adding support for constants in traits makes sense to me,
because it removes an arbitrary limitation and inconsistency, and removes
the need for people to work around this in ways that are much worse -- for
example, by having an implicit contract between the trait and the using
class, as shown in the RFC.

Regards,
Nikita

Mike Schinkel

4 years ago

> On Jul 5, 2022, at 5:38 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

The reaction to this RFC has been truly eye-opening to me.  It never occurred to me that Traits would be viewed so negatively by some on Internals.

Personally I have found Traits to be one of the VERY BEST features of PHP for a userland developer given their ability to reduce complexity and allow for a cleaner code architecture within the applications I have worked on. OTOH I have always found Traits to be an incomplete language feature whose design gaps I have handled via rigidly standardizing how I use them and by incorporating a lot of unfortunate boilerplate.

Though I was surprised at first that some people so strongly dislike Traits I then thought more about the incompleteness of Traits and wonder if that is not the reason they feel Traits are problematic?  I further wonder how their use-cases differ from the ones I have been involved with?

Given the three people who spoke strongly against them on this thread work heavily with PHP tools that make heavy use of reflection, code analysis, and/or work on PHP core I wonder if their dislike for Traits have a lot to do Trait-related problems they have when implementing PHP core itself, frameworks, ORMs, testing tools, etc. rather than userland development?

I am in no-way discounting the importance of core or tool development but I wonder if they recognized issues in the implementation-of and design decisions related-to Traits that most userland developers rarely ever see because of their core and/or tool development work?

Further, I wonder if their dislike of Traits is more of an X-Y problem?  IOW, that because they have seen issues with Traits they view the solution to tamp down on Traits rather than the solution being to fill in the design gaps and implementation issues with Traits?

------

So, can those who spoke against Traits please explain more details about:

1. How do Traits have "built-in accidental complexity?"

2. How does `use TRAIT1, TRAIT2, TRAIT3` semantics result in "mind-boggling over-complicated?"

3. What extra compatibility checks are required for Traits?

4. What are the potential error scenarios that are "unnecessary," why are they unnecessary, and what alternative could you envision?

5. What about the implementation of Traits do you strongly dislike, what type of implementation would be better, and could PHP change the implementation and still retain backward compatibility?

-----

I pose these questions in hopes to discern among Internals if Traits are actually the problem or if instead Traits could be improved to solve the concerns states in this tread, which might require some longer-term deprecation of some of the problematic aspects of Traits.

-Mike
P.S. I also want to talk about the issues I have with the RFC itself and what other things I see that I think are design gaps in Traits, but I don't want to create an email to the list with more than one focus.  I'll follow up later with those other issues.

Stephen Reay

4 years ago

> On 11 Jul 2022, at 09:10, Mike Schinkel <mike@newclarity.net> wrote:
>
>> On Jul 5, 2022, at 5:38 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
>
> The reaction to this RFC has been truly eye-opening to me.  It never occurred to me that Traits would be viewed so negatively by some on Internals.
>
> Personally I have found Traits to be one of the VERY BEST features of PHP for a userland developer given their ability to reduce complexity and allow for a cleaner code architecture within the applications I have worked on. OTOH I have always found Traits to be an incomplete language feature whose design gaps I have handled via rigidly standardizing how I use them and by incorporating a lot of unfortunate boilerplate.
>
> Though I was surprised at first that some people so strongly dislike Traits I then thought more about the incompleteness of Traits and wonder if that is not the reason they feel Traits are problematic?  I further wonder how their use-cases differ from the ones I have been involved with?
>
> Given the three people who spoke strongly against them on this thread work heavily with PHP tools that make heavy use of reflection, code analysis, and/or work on PHP core I wonder if their dislike for Traits have a lot to do Trait-related problems they have when implementing PHP core itself, frameworks, ORMs, testing tools, etc. rather than userland development?
>
> I am in no-way discounting the importance of core or tool development but I wonder if they recognized issues in the implementation-of and design decisions related-to Traits that most userland developers rarely ever see because of their core and/or tool development work?
>
> Further, I wonder if their dislike of Traits is more of an X-Y problem?  IOW, that because they have seen issues with Traits they view the solution to tamp down on Traits rather than the solution being to fill in the design gaps and implementation issues with Traits?
>
> ------
>
> So, can those who spoke against Traits please explain more details about:
>
> 1. How do Traits have "built-in accidental complexity?"
>
> 2. How does `use TRAIT1, TRAIT2, TRAIT3` semantics result in "mind-boggling over-complicated?"
>
> 3. What extra compatibility checks are required for Traits?
>
> 4. What are the potential error scenarios that are "unnecessary," why are they unnecessary, and what alternative could you envision?
>
> 5. What about the implementation of Traits do you strongly dislike, what type of implementation would be better, and could PHP change the implementation and still retain backward compatibility?
>
> -----
>
> I pose these questions in hopes to discern among Internals if Traits are actually the problem or if instead Traits could be improved to solve the concerns states in this tread, which might require some longer-term deprecation of some of the problematic aspects of Traits.
>
> -Mike
> P.S. I also want to talk about the issues I have with the RFC itself and what other things I see that I think are design gaps in Traits, but I don't want to create an email to the list with more than one focus.  I'll follow up later with those other issues.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

I hadn’t planned to get involved in this discussion - my name is only on the RFC because Shinji very graciously left it there when he took the skeleton of a proposal I’d written a while ago, and completed it in ways I never could have. So first off: thank you again Shinji for putting the effort in to bring this RFC to a vote. I very much appreciate all the effort you put into it.

For context, my work with PHP is split, between application development, and library development - so for some of it I’m trying to make sure the code is re-usable without having to jump through too many hoops (library dev), and for some of it I’m trying to re-use provided code, without having to jump through too many hoops (app dev).

I think one of the best descriptions I’ve seen about how traits **could** be used, is from an article (https://www.garfieldtech.com/blog/beyond-abstract <https://www.garfieldtech.com/blog/beyond-abstract>) Larry Garfield wrote just a couple of years after traits had been introduced. Larry presents the view that with the advent of traits in php, abstract classes could (should) be considered vestigial.

Having worked on library-style reusable code using abstract classes to provide extendable behaviour since around 2009, I really do like this approach, and I’d like to use traits a lot more like this.  But looking at numerous cases of existing abstract classes in my own work, even with all the other improvements in the language since 5.4, there’s still a single missing feature that makes "traits instead of abstract classes” a worse/nonviable option: constants.

Thanks again to Shinji, and to those who have voted yes so far.

Unnamed Person

4 years ago

On Tue, Jul 5, 2022 at 3: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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

I have changed my vote from No to Yes. I strongly dislike traits as
they are designed and also dislike most of the usages of them I've
encountered in the wild. This strongly dislike is why I originally
voted No, as enhancing a bad thing can make the bad thing get used
more, and that's not what I want. Despite this, I have opted to vote
Yes anyway.

shinji igarashi

4 years ago

Hello everyone!

I am not sure yet what the outcome of the vote will be, but if it passes, it
will need to be reviewed a bit more, so if you have time, please take a
look at the implementation of the trait constants RFC.
https://github.com/php/php-src/pull/8888

The vote will close on approximately 2022-07-19 22:00:00 (UTC).

Thanks!

--
Shinji Igarashi

2022年7月6日(水) 6:38 shinji igarashi <sji@sj-i.dev>:

shinji igarashi

4 years ago

Hello internals,

I just closed the vote for this RFC.
The constants in traits RFC has been accepted with 28 yes and 12 no votes.

Thank you everyone for participating in the discussion and vote!

--
Shinji Igarashi

2022年7月6日(水) 6:38 shinji igarashi <sji@sj-i.dev>: