> It’s always struck me as slightly odd that traits don’t support constants the 
> way classes and interfaces do.
> I tried to find an explanation of the lack of support in the original RFC, 
> and came up empty.
> 
> A consequent discussion in R11 has led me here.
> Can anyone working on internals explain why traits don’t allow constants 
> (either technically or philosophically)?
> Moreover, what’s the opinion(s) of the list, on adding support for this? 
> Would an RFC be needed? 

I'm in favor of adding it. I doubt there's any insurmountable technical 
obstacles.
(I work on a static analyzer for php (https://github.com/phan/phan) and don't 
expect technical issues with that proposal)
I personally find it inconvenient to put constants used by traits in different 
classes/interfaces or in properties.

Other languages allow adding constants to traits:

- Java allows defining constants on interfaces, which allow defining default 
method implementations like PHP traits
- 
https://doc.rust-lang.org/edition-guide/rust-2018/trait-system/associated-constants.html
 allows defining constants with values on traits
  (it also does various other things that impractical for php)

One thing to document/add tests for would be the resolution of `self::MY_CONST`.
In a trait, `self::method()` may be overridden by the method of the class 
that's using the trait.
I'd expect `self::MY_CONST` to be the same.

```php
<?php
trait T {
    public static function main() { self::foo(); }
    public static function foo() { echo "In trait\n"; }
}
class C {
    use T;
    public static function foo() { echo "In override\n"; }
}
C::main(); // outputs "In override"
```

Other thoughts:
- Should renaming and insteadof also work for constants? I'd assume yes 
https://www.php.net/manual/en/language.oop5.traits.php#language.oop5.traits.conflict
  (e.g. `use A, B { const A::MY_CONST insteadof B; }`)
- We already check if there are conflicting values when inheriting constants 
from an interface and another interface/trait.

Cheers,
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to