[RFC] [VOTE] Constants in traits

Hey Shinji,

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

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:

Hey Shinji,

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/

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!

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:

Hey Shinji,

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/

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

Den 2022-07-08 kl. 18:29, skrev Jordan LeDoux:

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

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.

--

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.