[RFC] [Discussion] Typed class constants

1 year ago by Larry Garfield — view source

unread

Hi Everyone,

A few years ago, Benas Seliuginas announced the "Typed constants" RFC (
https://externals.io/message/110755) which apparently had a
positive reception overall.
Unfortunately, there were some issues with the implementation (namely, with
the parser)
so the RFC was stuck.

A few weeks ago, I reached out to Benas whether he intended to resurrect
the proposal, but
due to time constraints, he couldn't, and was OK with me continuing it.
With some help from
Bob Weinand, I managed to overcome the implementation difficulties, and
adapted it
to the newly added type-related features.

Please find the updated RFC here:
https://wiki.php.net/rfc/typed_class_constants.

Regards,
Máté

One question:

public const int TEST1 = C;

In context, is that supposed to be TEST = C?

That example in particular is very confusing to me; I don't actually grok what it's even doing.

Aside from that, everything else looks good to me.

--Larry Garfield

1 year ago by ondrej@mirtes.cz — view source

unread

I fully support this RFC. PHPStan added support for PHPDoc types in class
constants some time ago - it’s useful to rely on the same constant type
even in subclasses when accessing them via static:: or $object::.

Hi Everyone,

A few years ago, Benas Seliuginas announced the "Typed constants" RFC (
https://externals.io/message/110755) which apparently had a
positive reception overall.
Unfortunately, there were some issues with the implementation (namely, with
the parser)
so the RFC was stuck.

A few weeks ago, I reached out to Benas whether he intended to resurrect
the proposal, but
due to time constraints, he couldn't, and was OK with me continuing it.
With some help from
Bob Weinand, I managed to overcome the implementation difficulties, and
adapted it
to the newly added type-related features.

Please find the updated RFC here:
https://wiki.php.net/rfc/typed_class_constants.

Regards,
Máté

--

Ondřej Mirtes

1 year ago by Mark Niebergall — view source

unread

I initiated a conversation about the typed constants RFC back in March
2022: https://externals.io/message/117406

I had updated the RFC page, but it looks like the changes were reverted in
December 2022. The updated version I was working on was:
https://wiki.php.net/rfc/typed_class_constants?rev=1648644637

The updated RFC looks good, thanks for working on it. You may want to
review the revised version I had worked on for implementation ideas, and
review the previous conversations.

The primary concept missing is declared but unassigned class constants,
which must then be assigned a value in the concrete class. See the section
on my revised version "Inheritance and variance". That'll be a question of
if that can or should be included in this RFC or not. It provides the most
value, allowing for inheritance from a parent class to ensure the value is
set and typed in the concrete class.

Mark Niebergall

I fully support this RFC. PHPStan added support for PHPDoc types in class
constants some time ago - it’s useful to rely on the same constant type
even in subclasses when accessing them via static:: or $object::.

Hi Everyone,

A few years ago, Benas Seliuginas announced the "Typed constants" RFC (
https://externals.io/message/110755) which apparently had a
positive reception overall.
Unfortunately, there were some issues with the implementation (namely,
with
the parser)
so the RFC was stuck.

A few weeks ago, I reached out to Benas whether he intended to resurrect
the proposal, but
due to time constraints, he couldn't, and was OK with me continuing it.
With some help from
Bob Weinand, I managed to overcome the implementation difficulties, and
adapted it
to the newly added type-related features.

Please find the updated RFC here:
https://wiki.php.net/rfc/typed_class_constants.

Regards,
Máté

--

Ondřej Mirtes

1 year ago by drealecs@gmail.com — view source

unread

Hi Everyone,

A few years ago, Benas Seliuginas announced the "Typed constants" RFC (
https://externals.io/message/110755) which apparently had a
positive reception overall.
Unfortunately, there were some issues with the implementation (namely, with
the parser)
so the RFC was stuck.

A few weeks ago, I reached out to Benas whether he intended to resurrect
the proposal, but
due to time constraints, he couldn't, and was OK with me continuing it.
With some help from
Bob Weinand, I managed to overcome the implementation difficulties, and
adapted it
to the newly added type-related features.

Please find the updated RFC here:
https://wiki.php.net/rfc/typed_class_constants.

Regards,
Máté

Hi Máté,

Looks great!

Two small things:

Why is object type not supported? I can't see a real reason and also
there is no explanation why.
In the examples for illegal values, it would be good to explain why they
are not legal.
I don't understand why "public const ?Foo M = null;" wouldn't be legal.
I think "?Foo" should work the same as "Foo|null" that would be legal.

Thank you,
Alex

1 year ago by kocsismate90@gmail.com — view source

unread

Hi Alexandru, Mark,

Why is object type not supported? I can't see a real reason and also
there is no explanation why.

Sorry for this, mentioning object as unsupported was an artifact from the
original version of the RFC which
was created back then when constants couldn't be objects. After your
comments, I removed the object type
from the list. Thank you for catching this issue!

In the examples for illegal values, it would be good to explain why
they are not legal.
I don't understand why "public const ?Foo M = null;" wouldn't be legal.
I think "?Foo" should work the same as "Foo|null" that would be legal.

It was there due to the same reason as above. I removed this example now.

I had updated the RFC page, but it looks like the changes were reverted in

December 2022. The updated version I was working on was:
https://wiki.php.net/rfc/typed_class_constants?rev=1648644637

Yeah, the original author of the RFC was surprised to find your changes in
his RFC (https://github.com/php/php-src/pull/5815#issuecomment-1356049048),
so he restored his original version.
Next time, please either consult with the author of an RFC if you intend to
modify the wording, or you can simply create a brand new RFC - even if it's
very similar to the original one (just don't
forget to add proper references).

The updated RFC looks good, thanks for working on it. You may want to

review the revised version I had worked on for implementation ideas, and
review the previous conversations.

I also saw your proposal, but to be honest, I'm not that fond of the idea.
This doesn't mean though that you shouldn't create a new RFC or an
implementation, as others may find it useful. If you kick off
the project, I'll surely try to review your work.

Regards,
Máté Kocsis

1 year ago by flaviohbatista@gmail.com — view source

unread

Hi Alexandru, Mark,

Why is object type not supported? I can't see a real reason and also
there is no explanation why.

Sorry for this, mentioning object as unsupported was an artifact from the
original version of the RFC which
was created back then when constants couldn't be objects. After your
comments, I removed the object type
from the list. Thank you for catching this issue!

In the examples for illegal values, it would be good to explain why
they are not legal.
I don't understand why "public const ?Foo M = null;" wouldn't be legal.
I think "?Foo" should work the same as "Foo|null" that would be legal.

It was there due to the same reason as above. I removed this example now.

I had updated the RFC page, but it looks like the changes were reverted in

December 2022. The updated version I was working on was:
https://wiki.php.net/rfc/typed_class_constants?rev=1648644637

Yeah, the original author of the RFC was surprised to find your changes in
his RFC (https://github.com/php/php-src/pull/5815#issuecomment-1356049048
),
so he restored his original version.
Next time, please either consult with the author of an RFC if you intend to
modify the wording, or you can simply create a brand new RFC - even if it's
very similar to the original one (just don't
forget to add proper references).

The updated RFC looks good, thanks for working on it. You may want to

review the revised version I had worked on for implementation ideas, and
review the previous conversations.

I also saw your proposal, but to be honest, I'm not that fond of the idea.
This doesn't mean though that you shouldn't create a new RFC or an
implementation, as others may find it useful. If you kick off
the project, I'll surely try to review your work.

Regards,
Máté Kocsis

Typed constants is a great addition, thanks Máté!

1 year ago by Mark Niebergall — view source

unread

Máté, Benas, Internals,

Hi Alexandru, Mark,

Why is object type not supported? I can't see a real reason and also
there is no explanation why.

Sorry for this, mentioning object as unsupported was an artifact from the
original version of the RFC which
was created back then when constants couldn't be objects. After your
comments, I removed the object type
from the list. Thank you for catching this issue!

In the examples for illegal values, it would be good to explain why
they are not legal.
I don't understand why "public const ?Foo M = null;" wouldn't be legal.
I think "?Foo" should work the same as "Foo|null" that would be legal.

It was there due to the same reason as above. I removed this example now.

I had updated the RFC page, but it looks like the changes were reverted in

December 2022. The updated version I was working on was:
https://wiki.php.net/rfc/typed_class_constants?rev=1648644637

Yeah, the original author of the RFC was surprised to find your changes in
his RFC (https://github.com/php/php-src/pull/5815#issuecomment-1356049048
),
so he restored his original version.
Next time, please either consult with the author of an RFC if you intend to
modify the wording, or you can simply create a brand new RFC - even if it's
very similar to the original one (just don't
forget to add proper references).

See https://externals.io/message/117406#117460 about contact attempts that
were made (with no response), and other discussions about why I used the
existing RFC instead of creating a new one. Next time I will just start a
new RFC if an author is non-responsive. This is also a bigger policy
question for other seemingly-abandoned RFCs. If it is agreed that a new RFC
should be created in this scenario, I will update
https://wiki.php.net/rfc/howto since that scenario is not specifically
covered.

That being said, the RFC was discussed publicly actively last year, and the
RFC was revised based on the public input. With the reverting, valuable
community input was dismissed. An effort should be made to address
applicable previous community input instead of just reverting it out.

I will work on a new RFC to follow this implementation to introduce
inheritance.

The updated RFC looks good, thanks for working on it. You may want to

review the revised version I had worked on for implementation ideas, and
review the previous conversations.

I also saw your proposal, but to be honest, I'm not that fond of the idea.
This doesn't mean though that you shouldn't create a new RFC or an
implementation, as others may find it useful. If you kick off
the project, I'll surely try to review your work.

That is fine to break it apart as a future RFC. I have seen too many real
world use cases where inheritance with typed constants would solve
problems. See https://externals.io/message/117406#117408 for an
explanation. Adding typed constants independently adds value, so it should
progress.

Regards,
Máté Kocsis

Overall, I'm happy to see that this is progressing again, thanks for
working on it.

Mark Niebergall

1 year ago by Dan Ackroyd — view source

unread

Hi Mark,

This is also a bigger policy question for other seemingly-abandoned
RFCs. If it is agreed that a new RFC should be created in this scenario,

I've added some notes on the page https://wiki.php.net/rfc/howto

I had some words already prepared from something I will post
separately, but may as well post here also:

Mailing list etiquette -
https://github.com/Danack/RfcCodex/blob/master/etiquette/mailing_list.md

Mailing list etiquette for young'uns -
https://github.com/Danack/RfcCodex/blob/master/etiquette/mailing_list_for_younguns.md

RFC attitudes -
https://github.com/Danack/RfcCodex/blob/master/etiquette/rfc_attitudes.md

RFC etiquette -
https://github.com/Danack/RfcCodex/blob/master/etiquette/rfc_etiquette.md

Most of the stuff in there is just etiquette rather than rules, so
probably isn't appropriate for the wiki.

I did leave Benas as an author to give him credit for the work he did.

Although well intentioned, that's probably quite a no-no. Putting
someone's name on something they don't necessarily agree with is
likely to cause drama. I've added a note on that also.

With the reverting, valuable community input was dismissed. An effort should
be made to address applicable previous community input instead of just
reverting it out.

Probably not.

It's up to other people to persuade RFC authors why something should
be included, rather than RFC authors having to take time and energy to
justify why they are reverting unapproved edits to their RFC.

But yep, if you want to do it as part of a separate RFC, go for it.

cheers
Dan
Ack

1 year ago by Mark Niebergall — view source

unread

Dan,

Hi Mark,

On Sat, 4 Feb 2023 at 00:22, Mark Niebergall mbniebergall@gmail.com
wrote:

This is also a bigger policy question for other seemingly-abandoned
RFCs. If it is agreed that a new RFC should be created in this scenario,

I've added some notes on the page https://wiki.php.net/rfc/howto

I had some words already prepared from something I will post
separately, but may as well post here also:

Mailing list etiquette -
https://github.com/Danack/RfcCodex/blob/master/etiquette/mailing_list.md

Mailing list etiquette for young'uns -

https://github.com/Danack/RfcCodex/blob/master/etiquette/mailing_list_for_younguns.md

RFC attitudes -
https://github.com/Danack/RfcCodex/blob/master/etiquette/rfc_attitudes.md

RFC etiquette -
https://github.com/Danack/RfcCodex/blob/master/etiquette/rfc_etiquette.md

Most of the stuff in there is just etiquette rather than rules, so
probably isn't appropriate for the wiki.

Thanks, these are actually very helpful and insightful.

I did leave Benas as an author to give him credit for the work he did.

Although well intentioned, that's probably quite a no-no. Putting
someone's name on something they don't necessarily agree with is
likely to cause drama. I've added a note on that also.

With the reverting, valuable community input was dismissed. An effort
should
be made to address applicable previous community input instead of just
reverting it out.

Probably not.

It's up to other people to persuade RFC authors why something should
be included, rather than RFC authors having to take time and energy to
justify why they are reverting unapproved edits to their RFC.

But yep, if you want to do it as part of a separate RFC, go for it.

I'll be doing that as a separate RFC, after the typed constants RFC settles.

cheers
Dan
Ack

1 year ago by Benas IML — view source

unread

[copy of the email that I have accidentally sent to Mark individually]

Hey,

As much as I appreciate your enthusiasm and ideas, adding your name on
my original RFC and editing its contents without my approval is not
acceptable. Especially considering that contents of the RFCs are a
direct representation of my stance and views on a particular feature.
As such, I would not like to have my name put on proposals that I have
never discussed nor proposed myself. In this case, I explicitly have
given Máté permission to continue working on this RFC and in taking it
under his wing.

That being said, feel free to open a new RFC yourself and copy the
contents of your previous proposal from the wiki's history tab.

Best regards,
Benas

P.S.: Next time, try also contacting me over Room 11 or GitHub, given
that I rarely check this email.

Máté, Benas, Internals,

Hi Alexandru, Mark,

Why is object type not supported? I can't see a real reason and also
there is no explanation why.

Sorry for this, mentioning object as unsupported was an artifact from the
original version of the RFC which
was created back then when constants couldn't be objects. After your
comments, I removed the object type
from the list. Thank you for catching this issue!

In the examples for illegal values, it would be good to explain why
they are not legal.
I don't understand why "public const ?Foo M = null;" wouldn't be legal.
I think "?Foo" should work the same as "Foo|null" that would be legal.

It was there due to the same reason as above. I removed this example now.

I had updated the RFC page, but it looks like the changes were reverted in

December 2022. The updated version I was working on was:
https://wiki.php.net/rfc/typed_class_constants?rev=1648644637

Yeah, the original author of the RFC was surprised to find your changes in
his RFC (https://github.com/php/php-src/pull/5815#issuecomment-1356049048
),
so he restored his original version.
Next time, please either consult with the author of an RFC if you intend to
modify the wording, or you can simply create a brand new RFC - even if it's
very similar to the original one (just don't
forget to add proper references).

See https://externals.io/message/117406#117460 about contact attempts that
were made (with no response), and other discussions about why I used the
existing RFC instead of creating a new one. Next time I will just start a
new RFC if an author is non-responsive. This is also a bigger policy
question for other seemingly-abandoned RFCs. If it is agreed that a new RFC
should be created in this scenario, I will update
https://wiki.php.net/rfc/howto since that scenario is not specifically
covered.

That being said, the RFC was discussed publicly actively last year, and the
RFC was revised based on the public input. With the reverting, valuable
community input was dismissed. An effort should be made to address
applicable previous community input instead of just reverting it out.

I will work on a new RFC to follow this implementation to introduce
inheritance.

The updated RFC looks good, thanks for working on it. You may want to

review the revised version I had worked on for implementation ideas, and
review the previous conversations.

I also saw your proposal, but to be honest, I'm not that fond of the idea.
This doesn't mean though that you shouldn't create a new RFC or an
implementation, as others may find it useful. If you kick off
the project, I'll surely try to review your work.

That is fine to break it apart as a future RFC. I have seen too many real
world use cases where inheritance with typed constants would solve
problems. See https://externals.io/message/117406#117408 for an
explanation. Adding typed constants independently adds value, so it should
progress.

Regards,
Máté Kocsis

Overall, I'm happy to see that this is progressing again, thanks for
working on it.

Mark Niebergall

1 year ago by Mark Niebergall — view source

unread

Benas,

[copy of the email that I have accidentally sent to Mark individually]

Hey,

As much as I appreciate your enthusiasm and ideas, adding your name on
my original RFC and editing its contents without my approval is not
acceptable. Especially considering that contents of the RFCs are a
direct representation of my stance and views on a particular feature.
As such, I would not like to have my name put on proposals that I have
never discussed nor proposed myself. In this case, I explicitly have
given Máté permission to continue working on this RFC and in taking it
under his wing.

My apologies. Good luck on the RFC.

That being said, feel free to open a new RFC yourself and copy the
contents of your previous proposal from the wiki's history tab.

I will be doing that. I'll give the typed constants RFC time to settle
first.

Best regards,
Benas

P.S.: Next time, try also contacting me over Room 11 or GitHub, given
that I rarely check this email.

Thanks for the updated contact information.

On Sat, 4 Feb 2023 at 02:22, Mark Niebergall mbniebergall@gmail.com
wrote:

Máté, Benas, Internals,

On Fri, Feb 3, 2023 at 7:34 AM Máté Kocsis kocsismate90@gmail.com
wrote:

Hi Alexandru, Mark,

Why is object type not supported? I can't see a real reason and
also
there is no explanation why.

Sorry for this, mentioning object as unsupported was an artifact from
the
original version of the RFC which
was created back then when constants couldn't be objects. After your
comments, I removed the object type
from the list. Thank you for catching this issue!

In the examples for illegal values, it would be good to explain
why
they are not legal.
I don't understand why "public const ?Foo M = null;" wouldn't be
legal.
I think "?Foo" should work the same as "Foo|null" that would be
legal.

It was there due to the same reason as above. I removed this example
now.

I had updated the RFC page, but it looks like the changes were
reverted in

December 2022. The updated version I was working on was:
https://wiki.php.net/rfc/typed_class_constants?rev=1648644637

Yeah, the original author of the RFC was surprised to find your
changes in
his RFC (
https://github.com/php/php-src/pull/5815#issuecomment-1356049048
),
so he restored his original version.
Next time, please either consult with the author of an RFC if you
intend to
modify the wording, or you can simply create a brand new RFC - even if
it's
very similar to the original one (just don't
forget to add proper references).

See https://externals.io/message/117406#117460 about contact attempts
that
were made (with no response), and other discussions about why I used the
existing RFC instead of creating a new one. Next time I will just start a
new RFC if an author is non-responsive. This is also a bigger policy
question for other seemingly-abandoned RFCs. If it is agreed that a new
RFC
should be created in this scenario, I will update
https://wiki.php.net/rfc/howto since that scenario is not specifically
covered.

That being said, the RFC was discussed publicly actively last year, and
the
RFC was revised based on the public input. With the reverting, valuable
community input was dismissed. An effort should be made to address
applicable previous community input instead of just reverting it out.

I will work on a new RFC to follow this implementation to introduce
inheritance.

The updated RFC looks good, thanks for working on it. You may want to

review the revised version I had worked on for implementation ideas,
and
review the previous conversations.

I also saw your proposal, but to be honest, I'm not that fond of the
idea.
This doesn't mean though that you shouldn't create a new RFC or an
implementation, as others may find it useful. If you kick off
the project, I'll surely try to review your work.

That is fine to break it apart as a future RFC. I have seen too many real
world use cases where inheritance with typed constants would solve
problems. See https://externals.io/message/117406#117408 for an
explanation. Adding typed constants independently adds value, so it
should
progress.

Regards,
Máté Kocsis

Overall, I'm happy to see that this is progressing again, thanks for
working on it.

Mark Niebergall

1 year ago by Claude Pache — view source

unread

Le 31 janv. 2023 à 22:01, Máté Kocsis kocsismate90@gmail.com a écrit :

Please find the updated RFC here:
https://wiki.php.net/rfc/typed_class_constants.

Regards,
Máté

Hi,

The RFC states that it is technically not possible to have a constant of effective type static or self. While this is probably correct for regular classes, this is not true for enums. The following code ostensibly works (https://3v4l.org/84W92):

enum qux {
    const foo_alias = self::foo;
    case foo;
}

var_dump(qux::foo_alias); // enum(qux::foo)

I think that self should be allowed here, because it is meaningful.

—Claude

1 year ago by kocsismate90@gmail.com — view source

unread

Hi Claude,

The RFC states that it is technically not possible to have a constant of

effective type static or self. While this is probably correct for
regular classes, this is not true for enums. The following code ostensibly
works (https://3v4l.org/84W92):

To be exact, defining class constants with the class itself as value is
already impossible: https://3v4l.org/J7C30 So this isn't really a
limitation imposed by the current RFC, but a new yet mentioned restriction
of
https://wiki.php.net/rfc/new_in_initializers. I'll try to make this clear
in the RFC text.

Since the discussion has been settled for quite a long time, I'd like to
start the vote in the second half of next week, unless new concerns are
brought up. So it's time to review the RFC carefully :)

Máté