Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Typed constants revisited »

Typed constants revisited

php.internals

Mark Niebergall

4 years ago
Hello All, In June 2020, Benas Seliuginas emailed this list ( https://externals.io/message/110755#110755) to gauge interest in typed constants. An RFC (https://wiki.php.net/rfc/typed_class_constants) was started and had an accompanying PR (https://github.com/php/php-src/pull/5815). At the time, Nikita Popov supported it for overall language consistency, and Sebastian Bergmann +1'd it for overall language consistency as well. The PR has since been closed without being merged, and the idea hasn't progressed since. I'd like to revisit the concept, gauge current interest, and pick the concept and work back up. Any more discussion items for or against the idea? I'm willing to do the work to pick it up where it was left off and get an RFC proposed through the normal process, and a working PR. This is my first foray into the PHP RFC process, and C code is not my forte, but I'll take it on. If anyone would be willing to pair/mentor/co-author with me, please let me know. Either way, I'll plan to work on it. This is the first of several concepts I have been tinkering with and seeing practical uses for. The next phase of work with different RFC would take this further with const inheritance, where const type must match. - Mark

Larry Garfield

4 years ago
On Wed, Mar 23, 2022, at 1:54 PM, Mark Niebergall wrote:
> Hello All, > > In June 2020, Benas Seliuginas emailed this list ( > https://externals.io/message/110755#110755) to gauge interest in typed > constants. An RFC (https://wiki.php.net/rfc/typed_class_constants) was > started and had an accompanying PR (https://github.com/php/php-src/pull/5815). > At the time, Nikita Popov supported it for overall language consistency, > and Sebastian Bergmann +1'd it for overall language consistency as well. > The PR has since been closed without being merged, and the idea hasn't > progressed since. > > I'd like to revisit the concept, gauge current interest, and pick the > concept and work back up. Any more discussion items for or against the idea? > > I'm willing to do the work to pick it up where it was left off and get an > RFC proposed through the normal process, and a working PR. This is my first > foray into the PHP RFC process, and C code is not my forte, but I'll take > it on. If anyone would be willing to pair/mentor/co-author with me, please > let me know. Either way, I'll plan to work on it. > > This is the first of several concepts I have been tinkering with and seeing > practical uses for. The next phase of work with different RFC would take > this further with const inheritance, where const type must match. > > - Mark
Is there a benefit to it other than "well everything else has types now, so..."? Even if it's esoteric, like in reflection-based meta programming? (I've been dabbling too much in that lately. :-) ) "Everything else does" isn't a compelling argument for me, but there may be others I'm not thinking of. --Larry Garfield

Mark Niebergall

4 years ago
On Wed, Mar 23, 2022 at 4:10 PM Larry Garfield <larry@garfieldtech.com> wrote:
> On Wed, Mar 23, 2022, at 1:54 PM, Mark Niebergall wrote: > > Hello All, > > > > In June 2020, Benas Seliuginas emailed this list ( > > https://externals.io/message/110755#110755) to gauge interest in typed > > constants. An RFC (https://wiki.php.net/rfc/typed_class_constants) was > > started and had an accompanying PR ( > https://github.com/php/php-src/pull/5815). > > At the time, Nikita Popov supported it for overall language consistency, > > and Sebastian Bergmann +1'd it for overall language consistency as well. > > The PR has since been closed without being merged, and the idea hasn't > > progressed since. > > > > I'd like to revisit the concept, gauge current interest, and pick the > > concept and work back up. Any more discussion items for or against the > idea? > > > > I'm willing to do the work to pick it up where it was left off and get an > > RFC proposed through the normal process, and a working PR. This is my > first > > foray into the PHP RFC process, and C code is not my forte, but I'll take > > it on. If anyone would be willing to pair/mentor/co-author with me, > please > > let me know. Either way, I'll plan to work on it. > > > > This is the first of several concepts I have been tinkering with and > seeing > > practical uses for. The next phase of work with different RFC would take > > this further with const inheritance, where const type must match. > > > > - Mark > > Is there a benefit to it other than "well everything else has types now, > so..."? Even if it's esoteric, like in reflection-based meta programming? > (I've been dabbling too much in that lately. :-) ) "Everything else does" > isn't a compelling argument for me, but there may be others I'm not > thinking of. > > --Larry Garfield >
Larry and Internals, To the benefits! On its own, typing class constants does help align them with other things like typed class properties, typed arguments, and method return types. There will come additional benefits though, and this would be phase 1. Phase 2 would be to introduce typed constants to be set by extending or implementing classes. Combining the two features would lead to better defined and usable class constants. For example, an interface could be: ``` interface DbTable { public const string TABLE_NAME; } ``` Which would then be implemented as: ``` class UserTable implements DbTable { public const string TABLE_NAME = 'user'; } ``` Thus ensuring `TABLE_NAME` is always set, and always returns a `string` type. See https://docs.laminas.dev/laminas-db/table-gateway/ for a real-world framework example where this feature _could_ be used. Another example I often see in my projects could be used with a similar example: ``` abstract class Bird { public const bool CAN_FLY; public const string FAMILY; public function canFly(): bool { return self::CAN_FLY; } } final class EmperorPenguin extends Bird { public const bool CAN_FLY = false; public const string FAMILY = 'penguin'; } ``` In this case, one could instead use typed class properties, but it feels improper since the values are static and unchanging. Immutability is a work around to this when implemented properly. This would simplify the solution while ensuring values remain unchanged. - Mark

Guilliam Xavier

4 years ago
Hi Mark, On Wed, Mar 23, 2022 at 11:55 PM Mark Niebergall <mbniebergall@gmail.com> wrote:
> (...) > > Another example I often see in my projects could be used with a similar > example: > > ``` > abstract class Bird > { > public const bool CAN_FLY; > public const string FAMILY; > public function canFly(): bool > { > return self::CAN_FLY; > } > } > final class EmperorPenguin extends Bird > { > public const bool CAN_FLY = false; > public const string FAMILY = 'penguin'; > } > ``` >
I had this "need" too (and used abstract static methods where the implementations just return a literal value...). Just 2 remarks: in abstract class Bird, shouldn't it be: - "*abstract* public const bool CAN_FLY;" (and same for FAMILY) - "return *static*::CAN_FLY;" ? Regards,
-- Guilliam Xavier

Mark Niebergall

4 years ago
Guilliam, On Fri, Mar 25, 2022 at 6:35 AM Guilliam Xavier <guilliam.xavier@gmail.com> wrote:
> Hi Mark, > > On Wed, Mar 23, 2022 at 11:55 PM Mark Niebergall <mbniebergall@gmail.com> > wrote: > >> (...) >> >> Another example I often see in my projects could be used with a similar >> example: >> >> ``` >> abstract class Bird >> { >> public const bool CAN_FLY; >> public const string FAMILY; >> public function canFly(): bool >> { >> return self::CAN_FLY; >> } >> } >> final class EmperorPenguin extends Bird >> { >> public const bool CAN_FLY = false; >> public const string FAMILY = 'penguin'; >> } >> ``` >> > > I had this "need" too (and used abstract static methods where the > implementations just return a literal value...). > > Just 2 remarks: in abstract class Bird, shouldn't it be: > - "*abstract* public const bool CAN_FLY;" (and same for FAMILY) > - "return *static*::CAN_FLY;" > ? >
I intentionally left `abstract` out of `public const bool CAN_FLY;` in the `abstract class` for consistency with the implementation with `interface`, which would also have to be `public const bool CAN_FLY;`. Currently `abstract` is only used in front of methods `abstract function doThing(): bool;`. Open to discussion - which way is ideal or preferred? That could be included as a subset of an RFC vote if a consensus during discussion isn't reached. Good correction, yes, `return static::CAN_FLY;` in that example in the concrete child class.

Guilliam Xavier

4 years ago
> I intentionally left `abstract` out of `public const bool CAN_FLY;` in the > `abstract class` for consistency with the implementation with `interface`, > which would also have to be `public const bool CAN_FLY;`. Currently > `abstract` is only used in front of methods `abstract function doThing(): > bool;`. Open to discussion - which way is ideal or preferred? That could be > included as a subset of an RFC vote if a consensus during discussion isn't > reached. >
I understand, but note that methods are implicitly abstract in an interface, but it must be explicit in an abstract class; and since I see the proposed feature mainly as a "replacement" for abstract static methods [whose all implementations just return a literal value]... (anyway, not super important)

Mark Niebergall

4 years ago
On Fri, Mar 25, 2022 at 10:55 AM Guilliam Xavier <guilliam.xavier@gmail.com> wrote:
> I intentionally left `abstract` out of `public const bool CAN_FLY;` in the >> `abstract class` for consistency with the implementation with `interface`, >> which would also have to be `public const bool CAN_FLY;`. Currently >> `abstract` is only used in front of methods `abstract function doThing(): >> bool;`. Open to discussion - which way is ideal or preferred? That could be >> included as a subset of an RFC vote if a consensus during discussion isn't >> reached. >> > > I understand, but note that methods are implicitly abstract in an > interface, but it must be explicit in an abstract class; and since I see > the proposed feature mainly as a "replacement" for abstract static methods > [whose all implementations just return a literal value]... (anyway, not > super important) >
Constants are not abstract in an interface - they must be assigned a value. Only classes and methods can be abstract. Within an abstract class it is not valid to have an abstract property. Properties can be defined `protected int $id;` and optionally assigned a value `protected int $id = 5;`, but cannot be `abstract protected int $id;`. So to me it makes more sense to have constants follow the same syntax as properties `public const bool CAN_FLY;` without the `abstract` keyword. An example: ``` abstract class Bird { public const bool CAN_FLY; protected bool $isExtinct; ``` This allows for similar behavior, similar requirements, and similar syntax - consistency ftw! There seems to be interest and good use cases (thanks Sara for the good practical example!). At this point I'm going to work on a new RFC with all the details and feedback from this discussion.

Guilliam Xavier

4 years ago
> Constants are not abstract in an interface - they must be assigned a > value. Only classes and methods can be abstract. Within an abstract class > it is not valid to have an abstract property. Properties can be defined > `protected int $id;` and optionally assigned a value `protected int $id = > 5;`, but cannot be `abstract protected int $id;`. >
That's the *current* state of the language indeed, but to me, [part of] your proposal looks like introducing "abstract constants"... Maybe I'm misunderstanding?
> So to me it makes more sense to have constants follow the same syntax as > properties `public const bool CAN_FLY;` without the `abstract` keyword. > > An example: > > ``` > abstract class Bird > { > public const bool CAN_FLY; > protected bool $isExtinct; > ``` > > This allows for similar behavior, similar requirements, and similar syntax > - consistency ftw! >
For similarity/consistency, the `$isExtinct` property should probably be [`public` and] `static` (actually `readonly` too, but cannot be both). But, again, we can also see some similarity with `static` *methods*, e.g.: ``` abstract class Bird { abstract public const bool CAN_FLY; abstract public static function isExtinct(): bool; } class Dove extends Bird { // NOTE: the following two lines are required (in the class definition) public const bool CAN_FLY = true; public function static isExtinct(): bool { return false; } } // var_dump(Dove::CAN_FLY); // var_dump(Dove::isExtinct()); ``` Besides, an uninitialized property must be initialized before first read, but is *not* required to be overridden/redefined (with a value) in a child class; so in this example (still hypothetical): ``` abstract class Bird { public const bool CAN_FLY; public static bool $isExtinct; } class Dodo extends Bird { // NOTE: the following two lines are commented out // public const bool CAN_FLY = false; // public static bool $isExtinct = true; } var_dump(Dodo::CAN_FLY); var_dump(Dodo::$isExtinct); ``` where would the [missing value for constant] error be: on the definition of class Dodo (like for an unimplemented abstract method), or only when trying to access Dodo::CAN_FLY (like for an uninitialized property)?
> > There seems to be interest and good use cases (thanks Sara for the good > practical example!). At this point I'm going to work on a new RFC with all > the details and feedback from this discussion. > >
Thanks & good luck! =)
-- Guilliam Xavier

Mark Niebergall

4 years ago
On Mon, Mar 28, 2022 at 6:54 AM Guilliam Xavier <guilliam.xavier@gmail.com> wrote:
> Constants are not abstract in an interface - they must be assigned a >> value. Only classes and methods can be abstract. Within an abstract class >> it is not valid to have an abstract property. Properties can be defined >> `protected int $id;` and optionally assigned a value `protected int $id = >> 5;`, but cannot be `abstract protected int $id;`. >> > > That's the *current* state of the language indeed, but to me, [part of] > your proposal looks like introducing "abstract constants"... Maybe I'm > misunderstanding? > > >> So to me it makes more sense to have constants follow the same syntax as >> properties `public const bool CAN_FLY;` without the `abstract` keyword. >> >> An example: >> >> ``` >> abstract class Bird >> { >> public const bool CAN_FLY; >> protected bool $isExtinct; >> ``` >> >> This allows for similar behavior, similar requirements, and similar >> syntax - consistency ftw! >> > > For similarity/consistency, the `$isExtinct` property should probably be > [`public` and] `static` (actually `readonly` too, but cannot be both). > > But, again, we can also see some similarity with `static` *methods*, e.g.: > > ``` > abstract class Bird > { > abstract public const bool CAN_FLY; > abstract public static function isExtinct(): bool; > } > class Dove extends Bird > { > // NOTE: the following two lines are required (in the class definition) > public const bool CAN_FLY = true; > public function static isExtinct(): bool { return false; } > } > // var_dump(Dove::CAN_FLY); > // var_dump(Dove::isExtinct()); > ``` > > Besides, an uninitialized property must be initialized before first read, > but is *not* required to be overridden/redefined (with a value) in a child > class; so in this example (still hypothetical): > > ``` > abstract class Bird > { > public const bool CAN_FLY; > public static bool $isExtinct; > } > class Dodo extends Bird > { > // NOTE: the following two lines are commented out > // public const bool CAN_FLY = false; > // public static bool $isExtinct = true; > } > var_dump(Dodo::CAN_FLY); > var_dump(Dodo::$isExtinct); > ``` > > where would the [missing value for constant] error be: on the definition > of class Dodo (like for an unimplemented abstract method), or only when > trying to access Dodo::CAN_FLY (like for an uninitialized property)? > > >> >> There seems to be interest and good use cases (thanks Sara for the good >> practical example!). At this point I'm going to work on a new RFC with all >> the details and feedback from this discussion. >> >> > > Thanks & good luck! =) >
I have updated the RFC https://wiki.php.net/rfc/typed_class_constants with more details and examples from this thread, and updated the RFC status to Under Discussion. Hopefully the updated RFC helps answer questions and clarifies what the proposal includes. Of note is the "Inheritance and variance" section, which details uses with abstracts and interfaces, plus the "Constant values" section which includes details about errors.

Alexandru Pătrănescu

4 years ago
Hey Mark, On Wed, Mar 30, 2022 at 6:03 AM Mark Niebergall <mbniebergall@gmail.com> wrote:
> > I have updated the RFC https://wiki.php.net/rfc/typed_class_constants with > more details and examples from this thread, and updated the RFC status to > Under Discussion. Hopefully the updated RFC helps answer questions and > clarifies what the proposal includes. >
Thanks for the RFC and the drive here. I personally see the benefit and I think it would be a nice addition. I think you should also update the "Supported types" section. Starting with enums, constants can also be objects. Once a good technical solution is found, any object would be supported probably https://wiki.php.net/rfc/new_in_initializers#future_scope I think that only void, never and callable types should not be supported, just like on properties.
> Of note is the "Inheritance and variance" section, which details uses with > abstracts and interfaces, plus the "Constant values" section which includes > details about errors. > > > > > > -- > > Guilliam Xavier > > >
Thanks, Alex

Pierre

4 years ago
Le 23/03/2022 à 23:10, Larry Garfield a écrit :
> Is there a benefit to it other than "well everything else has types now, so..."? Even if it's esoteric, like in reflection-based meta programming? (I've been dabbling too much in that lately. :-) ) "Everything else does" isn't a compelling argument for me, but there may be others I'm not thinking of. > > --Larry Garfield >
Hello, Well I was thinking myself that const being well... constant, and so always defined, type could be determined at compile time without the need to express it in a verbose way. PHP doesn't do any static type inference, but in this case, it could be done almost for free, am I wrong ? If it was determined at compile time, then the type checking on overrides would only be trivial, using the parent occurrence value inferred type. My point is that there's no need to express the type of a value, the value has already has a type. Regards,
-- Pierre

Mark Niebergall

4 years ago
Pierre, On Thu, Mar 24, 2022 at 1:04 AM Pierre <pierre-php@processus.org> wrote:
> Le 23/03/2022 à 23:10, Larry Garfield a écrit : > > Is there a benefit to it other than "well everything else has types now, > so..."? Even if it's esoteric, like in reflection-based meta programming? > (I've been dabbling too much in that lately. :-) ) "Everything else does" > isn't a compelling argument for me, but there may be others I'm not > thinking of. > > > > --Larry Garfield > > > Hello, > > Well I was thinking myself that const being well... constant, and so > always defined, type could be determined at compile time without the > need to express it in a verbose way. > > PHP doesn't do any static type inference, but in this case, it could be > done almost for free, am I wrong ? If it was determined at compile time, > then the type checking on overrides would only be trivial, using the > parent occurrence value inferred type. My point is that there's no need > to express the type of a value, the value has already has a type. >
As a developer, I don't *always* trust other developers implementing my code. Referring back to the Bird and EmperorPenguin example, the expected type for `public const bool CAN_FLY;` example MUST be a bool. If it isn't typed, another developer _could_ incorrectly set `CAN_FLY = 1;` or `CAN_FLY = 'true';` or even `CAN_FLY = 'Y';`. With class constants typed, they would get an error if setting it to anything other than a bool `CAN_FLY = true;` or `CAN_FLY = false;`. This further proliferates into sending the value of `CAN_FLY` into a typed argument like `protected function determineModeOfTransport(bool $canFly)` - if the constant is set incorrectly as a string or integer then more errors can occur. Typing class constants could also help static code analyzers more easily determine if there are bugs with unexpected value types being used in code. Instead of determining the value of the constant, the type of the constant could be used instead, providing a cleaner tokenized parsing. So you are correct, the const value does have a value that has a type, but there is no way to enforce which type the value is or to use const with inheritance, which is part of the bigger picture here.

Pierre

4 years ago
Le 24/03/2022 à 16:06, Mark Niebergall a écrit :
> So you are correct, the const value does have a value that has a type, but > there is no way to enforce which type the value is or to use const with > inheritance, which is part of the bigger picture here.
That was exactly my point: the type could simply implicitely be the one of the original value. Then the engine just has to use the existing covariance/contravariance rules for type checks based upon the guessed value type. This would fix the type safety issue you are referring to.
-- Regards

Mark Niebergall

4 years ago
Pierre, On Thu, Mar 24, 2022 at 9:20 AM Pierre <pierre-php@processus.org> wrote:
> Le 24/03/2022 à 16:06, Mark Niebergall a écrit : > > So you are correct, the const value does have a value that has a type, > but > > there is no way to enforce which type the value is or to use const with > > inheritance, which is part of the bigger picture here. > > That was exactly my point: the type could simply implicitely be the one > of the original value. > > Then the engine just has to use the existing covariance/contravariance > rules for type checks based upon the guessed value type. This would fix > the type safety issue you are referring to. >
I'd rather not use the "guessed value type" in code, that tends to lead to bugs: guessing = bugs. Explicitly declaring the type avoids the pitfalls of guessing and ensures code predictability. It also comes with added benefits, including self-documenting code, defined inheritance requirements (the way you describe would have BC breakage), and (for some IDEs) type hinting. Of note, many other languages already have typed constants. Yes this is the "everyone else is doing it" argument, but they had their valid reasons. Some are strong typed languages, others are not. See: - Go: https://go.dev/blog/constants - HVVM: https://docs.hhvm.com/hack/classes/type-constants - C: https://fresh2refresh.com/c-programming/c-constants/ - C++: https://en.cppreference.com/w/c/language/const - C#: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/const

Larry Garfield

4 years ago
On Thu, Mar 24, 2022, at 11:34 AM, Mark Niebergall wrote:
> Pierre, > > On Thu, Mar 24, 2022 at 9:20 AM Pierre <pierre-php@processus.org> wrote: > >> Le 24/03/2022 à 16:06, Mark Niebergall a écrit : >> > So you are correct, the const value does have a value that has a type, >> but >> > there is no way to enforce which type the value is or to use const with >> > inheritance, which is part of the bigger picture here. >> >> That was exactly my point: the type could simply implicitely be the one >> of the original value. >> >> Then the engine just has to use the existing covariance/contravariance >> rules for type checks based upon the guessed value type. This would fix >> the type safety issue you are referring to. >> > > I'd rather not use the "guessed value type" in code, that tends to lead to > bugs: guessing = bugs. Explicitly declaring the type avoids the pitfalls of > guessing and ensures code predictability. It also comes with added > benefits, including self-documenting code, defined inheritance requirements > (the way you describe would have BC breakage), and (for some IDEs) type > hinting. > > Of note, many other languages already have typed constants. Yes this is the > "everyone else is doing it" argument, but they had their valid reasons. > Some are strong typed languages, others are not. See: > > - Go: https://go.dev/blog/constants > - HVVM: https://docs.hhvm.com/hack/classes/type-constants > - C: https://fresh2refresh.com/c-programming/c-constants/ > - C++: https://en.cppreference.com/w/c/language/const > - C#: > https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/const
The addition of union types put the kibosh on successfully type guessing, I think. If you have a const that you'll allow a float or int in, and the default is 0, the guesser will guess int, not float, and then you can't allow a float. So "constant inheritance" is a use case for typed constants, even if constant inheritance is a rather edge-case situation to begin with. --Larry Garfield

Sara Golemon

4 years ago
On Thu, Mar 24, 2022 at 10:20 AM Pierre <pierre-php@processus.org> wrote:
> > That was exactly my point: the type could simply implicitely be the one > of the original value. > >
That works when the initial value is a literal, but what about when it's another cost? class Foo { const BAR = Baz::BAR; const BLING = MY_QUX; } What type are Foo::BAR and Foo::BLING? Suddenly these constants have dependent type and resolving it becomes less trivial. Also, what happens when this code is originally written when MY_QUX is a string, but then gets redefined (because it lives in another library we don't control). Allowing the author to put an explicit type removes all that uncertainty. -Sara

Rowan Collins

4 years ago
On 23/03/2022 18:54, Mark Niebergall wrote:
> The next phase of work with different RFC would take > this further with const inheritance, where const type must match.
I'm not sure it makes much sense to split this into two RFCs, and as far as I can see, the previous RFC included both features:
> Class constants are covariant. This means that the type of a class
constant is not allowed to be widen during inheritance. Or is there something more you mean by "const inheritance", which isn't covered by the RFC's examples? Regards,
-- Rowan Tommins [IMSoP]

Mark Niebergall

4 years ago
On Thu, Mar 24, 2022 at 1:00 PM Rowan Tommins <rowan.collins@gmail.com> wrote:
> On 23/03/2022 18:54, Mark Niebergall wrote: > > The next phase of work with different RFC would take > > this further with const inheritance, where const type must match. > > > I'm not sure it makes much sense to split this into two RFCs, and as far > as I can see, the previous RFC included both features: > > > Class constants are covariant. This means that the type of a class > constant is not allowed to be widen during inheritance. > > > Or is there something more you mean by "const inheritance", which isn't > covered by the RFC's examples? >
Agreed, the more discussion that is going on, the more I'm leaning towards to see this implemented in a single RFC. The true value comes with the full feature set. Correct the original RFC discusses some inheritance, but didn't expand it out the way I'm thinking. It only details ensuring the concrete class has a matching type. I'm proposing additionally allowing blank values to be set by the concrete class. Existing draft RFC (https://wiki.php.net/rfc/typed_class_constants): ``` class Test { private const int A = 1; public const mixed B = 1; public const int C = 1; } class Test2 extends Test { // this is legal (because Test::A is private) public const string A = 'a'; // this is legal public const int B = 0; // this is illegal public const mixed C = 0; } ``` What I'm proposing would further allow const without values in abstracts and interfaces, which require concrete classes to have a value: ``` abstract class Test { private const int A = 1; public const mixed B = 1; public const int C = 1; // no value set, this is legal, concrete classes must set value public const int D; } interface TestInterface { // no value set, this is legal public const string NAME; } class Test2 extends Test implements TestInterface { // this is legal (because Test::A is private) public const string A = 'a'; // this is legal public const int B = 0; // these are required due to inheritance public const int D = 5; public const string NAME = 'EmperorPenguin'; // this is illegal public const mixed C = 0; } ```