Hi Nicolas: > On 22 Jun 2022, at 17:31, Nicolas Grekas <nicolas.grekas+...@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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
