Re: [PHP-DEV] [RFC] [Under Discussion] Constants in traits

This is only part of a thread. view whole thread
June 22, 2022 21:34 (shinji igarashi)
Wow, nested blockquotes are disappeared completely in :-)

If anyone is reading the discussion via and misses the context,
please check the source of the email.


Shinji Igarashi

2022年6月23日(木) 6:04 shinji igarashi <>:
> > Hello Larry, Stefan, and Nicolas! > > Thanks for the responses. > > >>> Why were constants left out of traits previously > >> That! > > So, my working assumption is: it wasn’t something I really thought about. > > From what I've read in the old ML archives of discussions on introducing > traits to PHP, perhaps constants simply were not among the considerations.. > The phrase "constants" is rarely even mentioned in the discussion. > > >> why the default value of a const (and a property) could not be changed > >> by the class importing the trait? > > My answer to this question is that there can be more than one policy for > handling state conflicts, and PHP has implemented one restricted approach > for now and has not yet addressed another policy after that. > > Based on my limited understanding, let me briefly summarize the story. > Please point out if anything is incorrect. > > First, it should be noted that in the original trait paper, the trait has only > behavior and no state, thereby avoiding the state conflict problem in > diamond inheritance. In the original trait paper, it is assumed that the state > is provided on the composing class side and accessed from the trait > through the accessor [1]. With this pure approach in mind, PHP allows > abstract methods to be declared in the trait, and the composing class > implements the requested accessors. > > The problem with this pure approach is obvious: there is too much > boilerplate in creating and using traits. Traits provide class components, > and serious class components will often want to access some state. > During the initial discussions, many messages were sent to internals about > whether to allow properties in traits, and what form this should take. > > By the way, historically, there have been two typical approaches to the > diamond inheritance state collision problem: one is to merge the state of > the common ancestor, and the other is to have independent state for each > common ancestor in the separate "path". Since different use cases require > one or the other, programming languages sometimes have features that > allow programmers to use these two methods selectively, such as virtual > inheritance in C++. > > Where having state becomes tricky is when the diamond problem occurs. > If there are no conflicts, it does not matter if a trait has state. And even if > there is a conflict, if the programming language defaults to either merge or > having independent state, that default will work fine for half of the use cases. > > PHP strikes a balance in this problem, allowing traits to define properties, > and choosing to deal with conflicts by merging states, and also marking > any conflicting definitions with different visibility or default values as an > error, as a sign of an unintended name conflict [2]. > > This is how PHP came to have properties in traits in its current form; I > believe that the story of having data definitions instead of behaviors in > traits have barely settled itself, and the story of constant definitions was > simply forgotten or put on the back burner. > > While not the main topic, current PHP does not yet provide a way to allow > common ancestors to have independent states. There are several > references to Stateful Traits in older discussions[3]. Stateful Traits default > to trait state as trait local, but allow the programmer to selectively use > merge behavior as needed. On the contrary, since PHP defaults to merge > behavior, there may be a future extension that allows trait local to be > explicitly declared. This option has even been mentioned in the old > discussions, but it has not caught the attention of many people and has > been on hold for more than a decade [4]. Perhaps it is time to reconsider > this also. > > >> And I'd also be happy to see an implementation of this before voting > > Yeah of course! It is generally working on my end, and I'll send PR within > a few days after adding a few more minor test cases. > > [1] > [2] > [3] > [4] > > Thanks! > > -- > Shinji Igarashi > > 2022年6月23日(木) 2:39 Stefan Marr <>: > > > > > Hi Nicolas: > > > > > On 22 Jun 2022, at 17:31, Nicolas Grekas> wrote: > > > > > > > I'd like to start a discussion on an RFC to allow defining constants in traits. > > > > > > > > > > > > I'm looking forward to your feedback, including corrections on English wordings. > > > > > > > > Thanks! > > > > > > > > -- > > > > Shinji Igarashi > > > > > > I am initially lukewarm. One thing not addressed in the RFC that should be: Why were constants left out of traits previously > > > > Hm. This isn’t something that I remember coming up specifically back then. > > If it had been discussed in more detail, I’d probably have included it in the RFC. > > So, my working assumption is: it wasn’t something I really thought about. > > > > > > > and what has changed to make them make sense to include now? (I don't recall, honestly, so I have no strong feelings one way or the other yet.) > > > > I am not sure there are reasons to specifically exclude them though. > > The RFC, reading over it briefly, and having been away for very long from the topic, seems sensible to me. > > Taking a very restrictive approach, seems sensible to me, too. > > > > > I'm also wondering why the default value of a const (and a property) could not be changed by the class importing the trait? This sometimes hits me and the original RFC doesn't explain why this is needed. > > > > For constants, I’d lean towards not allowing changes. > > If you need to parameterize the trait with a value, having an abstract method return it seems a much clearer way of doing it. > > Then all parts of the system know “it’s not a constant” and I need to cater for different values. > > > > The reason for the strict policies on property conflicts was to keep it simple. > > Be conservative, and avoid silent bugs. > > > > > > Please take everything I say with an extra pinch of salt. > > It has been a long time. > > > > Best regards > > Stefan > > > > -- > > Stefan Marr > > School of Computing, University of Kent > > > > > >