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 <ocram...@gmail.com>: > > Hey Shinji, > > On Tue, 5 Jul 2022 at 23:39, shinji igarashi <s...@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/ > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
