All,
Given that we can now declare a class constant as public, protected, or
private, can we also declare them final in 7.2?
Ideally, this code would error on line 18 rather than 15.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com
All,
Given that we can now declare a class constant as public, protected, or
private, can we also declare them final in 7.2?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.
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
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
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.
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.
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]