[RFC] [Under Discussion] Constants in traits

  118039
June 21, 2022 21:33 sji@sj-i.dev (shinji igarashi)
Hello everyone!

I'd like to start a discussion on an RFC to allow defining constants in traits.
https://wiki.php.net/rfc/constants_in_traits

I'm looking forward to your feedback, including corrections on English wordings.

Thanks!

--
Shinji Igarashi
  118055
June 22, 2022 16:09 larry@garfieldtech.com ("Larry Garfield")
On Tue, Jun 21, 2022, at 4:33 PM, shinji igarashi wrote:
> Hello everyone! > > I'd like to start a discussion on an RFC to allow defining constants in traits. > https://wiki.php.net/rfc/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, 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.) --Larry Garfield
  118056
June 22, 2022 16:31 nicolas.grekas+php@gmail.com (Nicolas Grekas)
> > > > I'd like to start a discussion on an RFC to allow defining constants in > traits. > > https://wiki.php.net/rfc/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, 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.) >
That! 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. I added Stefan Marr in the loop in case he still checks this email address and would like to shed some light on those questions. WDYT Stefan? And I'd also be happy to see an implementation of this before voting, to be sure this is something that can be achieved without too many troubles. Do you think this is possible? Cheers, Nicolas
  118059
June 22, 2022 17:39 internals@lists.php.net ("Stefan Marr via internals")
Hi Nicolas:

> On 22 Jun 2022, at 17:31, Nicolas Grekas grekas+php@gmail.com> wrote: > > > I'd like to start a discussion on an RFC to allow defining constants in traits. > > https://wiki.php.net/rfc/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 https://stefan-marr.de/research/
  118064
June 22, 2022 21:04 sji@sj-i.dev (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] https://dl.acm.org/doi/10.1145/1119479.1119483 [2] https://externals.io/message/51007#51072 [3] https://link.springer.com/chapter/10.1007/978-3-540-71836-9_4 [4] https://externals.io/message/35800 Thanks! -- Shinji Igarashi 2022年6月23日(木) 2:39 Stefan Marr <php@stefan-marr.de>:
> > Hi Nicolas: > > > On 22 Jun 2022, at 17:31, Nicolas Grekas grekas+php@gmail.com> wrote: > > > > > I'd like to start a discussion on an RFC to allow defining constants in traits. > > > https://wiki.php.net/rfc/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 > https://stefan-marr.de/research/ > >
  118065
June 22, 2022 21:34 sji@sj-i.dev (shinji igarashi)
Wow, nested blockquotes are disappeared completely in externas.io :-)

If anyone is reading the discussion via externals.io and misses the context,
please check the source of the email.
https://externals.io/email/118064/source

Thanks!

--
Shinji Igarashi

2022年6月23日(木) 6:04 shinji igarashi <sji@sj-i.dev>:
> > 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] https://dl.acm.org/doi/10.1145/1119479.1119483 > [2] https://externals.io/message/51007#51072 > [3] https://link.springer.com/chapter/10.1007/978-3-540-71836-9_4 > [4] https://externals.io/message/35800 > > Thanks! > > -- > Shinji Igarashi > > 2022年6月23日(木) 2:39 Stefan Marr <php@stefan-marr.de>: > > > > > Hi Nicolas: > > > > > On 22 Jun 2022, at 17:31, Nicolas Grekas grekas+php@gmail.com> wrote: > > > > > > > I'd like to start a discussion on an RFC to allow defining constants in traits. > > > > https://wiki.php.net/rfc/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 > > https://stefan-marr.de/research/ > > > >
  118061
June 22, 2022 18:12 claude.pache@gmail.com (Claude Pache)
> Le 21 juin 2022 à 23:33, shinji igarashi <sji@sj-i.dev> a écrit : > > Hello everyone! > > I'd like to start a discussion on an RFC to allow defining constants in traits. > https://wiki.php.net/rfc/constants_in_traits > > I'm looking forward to your feedback, including corrections on English wordings. > > Thanks! > > -- > Shinji Igarashi >
Hi, Some time ago, I migrated part of some class implementation into a trait, and I was surprised that it resulted in a syntax error, because constants were not supported in traits. In my case, I could trivially resolve the issue by morphing the (private) constant into a static property (semantically less correct, but pragmatically simpler); but I was feeling that it is yet one more inconsistency of PHP: Why on earth are static properties supported, but not constants? So, this is a welcome addition (or, rather, a welcome correction of an oversight). —Claude
  118158
July 2, 2022 01:30 sji@sj-i.dev (shinji igarashi)
Hello, everyone!

I have updated the RFC for constants in traits to reflect the discussion at
ML and answer some additional questions, as well as add sections on
comparisons to other languages and future scope, and modify some
sentences for clarity.
https://wiki.php.net/rfc/constants_in_traits

If there is no additional discussion, I will open the voting around
2022-07-05 22:00 (UTC) .

Thanks!

--
Shinji Igarashi

2022年6月22日(水) 6:33 shinji igarashi <sji@sj-i.dev>:
> > Hello everyone! > > I'd like to start a discussion on an RFC to allow defining constants in traits. > https://wiki.php.net/rfc/constants_in_traits > > I'm looking forward to your feedback, including corrections on English wordings. > > Thanks! > > -- > Shinji Igarashi
  118183
July 4, 2022 22:42 sji@sj-i.dev (shinji igarashi)
Hello!

I have updated the RFC for constants in traits to clearly state
that Enumerations can use traits having constants.
https://wiki.php.net/rfc/constants_in_traits

As I said before, if there is no further discussion, I will open
the voting tomorrow.

Thanks!

--
Shinji Igarashi

2022年7月2日(土) 10:30 shinji igarashi <sji@sj-i.dev>:
> > Hello, everyone! > > I have updated the RFC for constants in traits to reflect the discussion at > ML and answer some additional questions, as well as add sections on > comparisons to other languages and future scope, and modify some > sentences for clarity. > https://wiki.php.net/rfc/constants_in_traits > > If there is no additional discussion, I will open the voting around > 2022-07-05 22:00 (UTC) . > > Thanks! > > -- > Shinji Igarashi > > 2022年6月22日(水) 6:33 shinji igarashi <sji@sj-i.dev>: > > > > Hello everyone! > > > > I'd like to start a discussion on an RFC to allow defining constants in traits. > > https://wiki.php.net/rfc/constants_in_traits > > > > I'm looking forward to your feedback, including corrections on English wordings. > > > > Thanks! > > > > -- > > Shinji Igarashi