[RFC] [Discussion] Typed class constants

Larry Garfield

3 years ago

On Tue, Jan 31, 2023, at 3:01 PM, Máté Kocsis wrote:

> 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

Ondřej Mirtes

3 years ago

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::.

On Tue 31. 1. 2023 at 22:01, Máté Kocsis <kocsismate90@gmail.com> wrote:

> 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

Mark Niebergall

3 years ago

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


On Tue, Jan 31, 2023 at 5:55 PM Ondřej Mirtes <ondrej@mirtes.cz> wrote:

Alexandru Pătrănescu

3 years ago

On Tue, Jan 31, 2023 at 11:01 PM Máté Kocsis <kocsismate90@gmail.com> wrote:

> 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:
1. Why is object type not supported? I can't see a real reason and also
there is no explanation why.
2. 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

Máté Kocsis

3 years ago

Hi Alexandru, Mark,

> 1. 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!

> 2. 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

Flávio Heleno

3 years ago

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

> Hi Alexandru, Mark,
>
>
> > 1. 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!
>
>
> > 2. 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é!

Mark Niebergall

3 years ago

Máté, Benas, Internals,

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

> Hi Alexandru, Mark,
>
>
> > 1. 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!
>
>
> > 2. 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

Dan Ackroyd

3 years ago

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.

> 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

Mark Niebergall

3 years ago

Dan,

On Sat, Feb 4, 2023 at 8:34 AM Dan Ackroyd <Danack@basereality.com> wrote:

> 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.

Benas IML

3 years ago

[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.

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

Mark Niebergall

3 years ago

Benas,

On Sun, Feb 5, 2023 at 9:29 AM Benas IML <benas.molis.iml@gmail.com> wrote:

> [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.

Claude Pache

3 years ago

> 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):

```php
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

Máté Kocsis

3 years ago

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é

Claude Pache

3 years ago

Hi Máté,

I think you didn’t understand me, so I’ll restate:

> To be exact, defining class constants with the class itself as value is already impossible: https://3v4l.org/J7C30

No, for some specific sort of class, namely for enum, it is absolutely possible to define a constant with an  effective type of `self`: https://3v4l.org/r8Jo3

```php
enum A {
case foo;
const bar = self::foo;
}

var_dump(A::bar instanceof A); // true
```

—Claude

Máté Kocsis

3 years ago

Hi Claude,

No, I didn't misunderstand you, I just didn't specify my answer enough:

Enums can be assigned to their own class constants because of their special
behavior, namely that enum cases are evaluated and then instantiated right
away,
during the compilation of the enum case. This is easily possible because
enum cases are scalars and cannot refer to external things.

However, you cannot do the same with class constants because the class
itself has to be registered after all the validations are done, plus the
global constant referring
to the class has to be evaluated too. Unfortunately, I am not able to
detail the problem any deeper, but I can tell you that your enum example is
not applicable for class constants.

Regards,
Máté

Máté Kocsis

3 years ago

Hey Claude,

Sorry for my last response, I didn't understand you indeed... Enums really
do support self/static types. So I've just updated the implementation +
removed the restrictions
in question from the RFC + added a future scope section containing some
information about the existing restrictions.

Thank you very much for catching this! As the RFC text is now finalized, I
intend to start the vote on Monday.

Regards,
Máté

Claude Pache

3 years ago

> Le 23 févr. 2023 à 16:51, Máté Kocsis <kocsismate90@gmail.com> a écrit :
>
> As the RFC text is now finalized, I intend to start the vote on Monday.
>
> Regards,
> Máté

Hi Máté,

I’ve just read the new version of the RFC. It seems ok to me. Just a small remark:

Although they are not explicitly mentioned, I assume that typed constants are also available on traits?

—Claude

Máté Kocsis

3 years ago

Hi Claude,

> Although they are not explicitly mentioned, I assume that typed constants
> are also available on traits?
>

Yes, sure! I've just clarified the RFC by mentioning this fact as well as
adding an example.

Regards,
Máté