Class Constant Finalization

php.internals

Scott Arciszewski

9 years ago
All, Given that we can now declare a class constant as public, protected, or private, can we also declare them final in 7.2? https://3v4l.org/rJG0V Ideally, this code would error on line 18 rather than 15. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com>

Nikita

9 years ago
> On 25 Jan 2017, at 09:48, Scott Arciszewski <scott@paragonie.com> wrote: > > All, > > Given that we can now declare a class constant as public, protected, or > private, can we also declare them final in 7.2? > > https://3v4l.org/rJG0V > > Ideally, this code would error on line 18 rather than 15. > > Scott Arciszewski > Chief Development Officer > Paragon Initiative Enterprises <https://paragonie.com>
In my book, ideally, there would be no class constant inheritance as inherited constants don't really make sense when they are known at compile time. People often use this feature in order to get things like this to work: class LibLevelClass { const FOO = "default"; public function doSomething() { echo "the value of FOO is: " . static::FOO; } } class ExtensionClass { const FOO = "custom"; } But this approach is error prone due to untyped nature of constants (one could override the constant with an array value). In the end this inheritance is always unnecessary.

Stas Malyshev

9 years ago
Hi!
> Given that we can now declare a class constant as public, protected, or > private, can we also declare them final in 7.2?
That doesn't make much sense to me. Constant belongs to a class. I don't see much utility in "no class extending from this one can define constant with the same name". final makes sense when the alternative is override, and you want to exclude it. But since there's no override here, no point to exclude anything.
-- Stas Malyshev smalyshev@gmail.com

Stas Malyshev

9 years ago
Hi!
>> Given that we can now declare a class constant as public, protected, or >> private, can we also declare them final in 7.2? > > That doesn't make much sense to me. Constant belongs to a class. I don't > see much utility in "no class extending from this one can define > constant with the same name". final makes sense when the alternative is > override, and you want to exclude it. But since there's no override > here, no point to exclude anything.
Adding to this, you kind of can simulate it with static::, as Nikita described, but if you go as far, you probably know what you're doing and then you should be allowed to do it. Not that I see much point in doing it, but if you want to...
-- Stas Malyshev smalyshev@gmail.com

Net Mo

9 years ago
They don't belong to a class only, but to a class and all its descendants. Ideally, descendants should not inherit constants (or anything static), but we can't change that now, so final could make sense here. Basically, they should work exactly like static fields, except that static fields can be re-assigned, while constants may not.

Niklas Keller

9 years ago
2017-01-25 9:27 GMT+01:00 Wes <netmo.php@gmail.com>:
> They don't belong to a class only, but to a class and all its descendants. > Ideally, descendants should not inherit constants (or anything static), but > we can't change that now, so final could make sense here. Basically, they > should work exactly like static fields, except that static fields can be > re-assigned, while constants may not. >
Well, we can deprecate them and remove it with PHP 8.

Rowan Collins

9 years ago
On 25/01/2017 08:49, Niklas Keller wrote:
> 2017-01-25 9:27 GMT+01:00 Wes <netmo.php@gmail.com>: > >> They don't belong to a class only, but to a class and all its descendants. >> Ideally, descendants should not inherit constants (or anything static), but >> we can't change that now, so final could make sense here. Basically, they >> should work exactly like static fields, except that static fields can be >> re-assigned, while constants may not. >> > Well, we can deprecate them and remove it with PHP 8. >
You mean, make all constants non-inheritable? Why? Late static binding is a documented language feature, I don't see why it's any weirder for constants to participate in it than static fields and methods. Regards,
-- Rowan Collins [IMSoP]