Proposal: Forbidding constant "overriding"

[Majkl578]

Const overrides violate const invariants and are not LSP-compliant (types can be changed randomly).

There may be dragons when constants are used with static:: (sniff request to forbid that: slevomat/coding-standard#473) or $object::.

Any occurence of a constant override should be (abstract) method instead.

Edge case: constants like NAME on each member of a tree?

[strongholdmedia]

That is absolutely not an "edge case" but PHP's implementation of "one-time programmability".

I think that this behavior is great because you may override it in every descendant once, then (mostly) prevent further tampering.

Changing the type of it if not already alarmed upon, however, should be implemented in my opinion, (unless it is declared as NULL by default, which is what we do sometimes to mimic abstract constant behavior - we certainly do change it always to the same type though).

I am unsure if the above could be done in any concise and straightforward manner.

[Majkl578]

I think that this behavior is great because you may override it in every descendant once

I would agree if constants were not implicitly inherited, but as it is now it's only confusing and error-prone. Also constants can't be final which makes the problem even worse.

[strongholdmedia]

I guess this "confusion" stuff be "Java-specific".

In C#, for instance, you may declare a constant as "new" in a descendant, so that it is actually overridden (and even that is needed only due to compile-time substitution); whilst in C, you can just #undef practically anything to redefine it.

What I do agree to is, however, that regardless of "declaring" strict types, no notice or anything is received when the type of a constant is changed; and also there seems no way to declare the type of a class constant.

[Majkl578]

@ondrejmirtes WDYT about this one, is it worth pursuing?