Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ReflectionClass: show enums differently from classes, test output #15956

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

DanielEScherzer
Copy link
Member

@DanielEScherzer DanielEScherzer commented Sep 19, 2024

While internally enums are mostly the same as classes, their output in
ReflectionClass::__toString() should show the enum as the developer wrote it,
rather than as the engine stored it. Accordingly

  • Say that the enum is an enum, not a final class

  • Include the backing type, if any, in the declaration line

  • List enum cases separately from constants, and show the underlying values, if
    any

Also add tests for the output - the tests are added in the first commit, so
that the changes in the second commit can be more easily confirmed.

GH-15766

@nielsdos
Copy link
Member

I didn't look at the code, but in general I'm in favor of the idea. It's too late for 8.4 though, and this may have BC implications if people rely on the output. So when we start on 8.5 you may need to email the ML to pitch this.

@DanielEScherzer
Copy link
Member Author

I didn't look at the code, but in general I'm in favor of the idea. It's too late for 8.4 though, and this may have BC implications if people rely on the output. So when we start on 8.5 you may need to email the ML to pitch this.

Yeah, there is no rush on this. Just wondering though, is the next version going to be 8.5, or 9.0? I wasn't able to find documentation on how many minor releases are done for each major release - since the github milestones show 8.4 and then 9.0, I assumed 9.0 was next - whichever it is, this can totally wait

@nielsdos
Copy link
Member

The version will be bumped to 9.0 if it's necessary to do so (e.g. large engine changes).
The next version is most likely 8.5 unless decided otherwise.

@DanielEScherzer
Copy link
Member Author

Mailing list discussion is at https://externals.io/message/126504, I'll rebase this patch once it is ready to merge

@iluuu1994
Copy link
Member

iluuu1994 commented Feb 25, 2025

Remove the UnitEnum and BackedEnum interfaces from the list of interfaces implemented

Not sure there's a reason to do that. After all, reflection is intentionally explicit.

For comparison: https://3v4l.org/ecsMZ

Class [ class Foo implements Stringable ] {

@DanielEScherzer
Copy link
Member Author

Remove the UnitEnum and BackedEnum interfaces from the list of interfaces implemented

Not sure there's a reason to do that. After all, reflection is intentionally explicit.

Reverted that part

Copy link
Member

@iluuu1994 iluuu1994 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code looks correct. I don't have any other objections.

In preparation for improving it, phpGH-15766
While internally enums are mostly the same as classes, their output in
`ReflectionClass::__toString()` should show the enum as the developer wrote it,
rather than as the engine stored it. Accordingly

- Say that the enum is an enum, not a final class

- Include the backing type, if any, in the declaration line

- List enum cases separately from constants, and show the underlying values, if
any

phpGH-15766
@DanielEScherzer
Copy link
Member Author

Merging is blocked
Commits must have verified signatures.

Is this a new thing? Do I need to set up verified signatures now?

@nielsdos
Copy link
Member

nielsdos commented Mar 20, 2025

Merging is blocked
Commits must have verified signatures.

Is this a new thing? Do I need to set up verified signatures now?

Since we are the ones who're gonna merge it: no, we have to have signatures.
We already started requiring signatures after the xz incident last year, but the rule wasn't enforced on GH yet.

@iluuu1994
Copy link
Member

Indeed. Nonetheless, since merges made by the GH UI are signed using GH's own key, I don't understand why they would block this...

@DanielEScherzer
Copy link
Member Author

Indeed. Nonetheless, since merges made by the GH UI are signed using GH's own key, I don't understand why they would block this...

Merges can be done in the UI? https://wiki.php.net/vcs/gitfaq says

You cannot use the Merge button on GitHub for that. The PHP Organization on GitHub will not accept contributors. It's only for mirroring!

Does that need update?

@iluuu1994
Copy link
Member

Does that need update?

Indeed, I fixed that just now.

After a quick chat with @TimWolla, it's probably best to disable this setting again. While the people with repo access should all sign their commits, we don't want to impose that on first contributors. The message makes it sound like it's an action the users must take, when that's not accurate. Unless we do a fast-forward merge, which doesn't happen too often, the signature is discarded anyway.

Unfortunate, but oh well.

@iluuu1994
Copy link
Member

Oh and @DanielEScherzer, it's still very much advisable for you to sign your commits, as you're a regular contributor. 🙂

Copy link
Member

@iluuu1994 iluuu1994 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

So that we don't need to loop through all of the constants multiple times

Looping multiple times might even end up being faster due to avoiding allocations. We should pick whichever solution is the simplest.

That said, this solution is also fine.

@DanielEScherzer
Copy link
Member Author

LGTM

So that we don't need to loop through all of the constants multiple times

Looping multiple times might even end up being faster due to avoiding allocations. We should pick whichever solution is the simplest.

That said, this solution is also fine.

I think the current version is simplest, so I plan to merge this in a few days if there is no other feedback

Copy link
Member

@nielsdos nielsdos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor nits, otherwise ok

count = zend_hash_num_elements(&ce->constants_table);
smart_str_append_printf(str, "%s - Constants [%d] {\n", indent, count);
if (count > 0) {
int total_count = zend_hash_num_elements(&ce->constants_table);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
int total_count = zend_hash_num_elements(&ce->constants_table);
uint32_t total_count = zend_hash_num_elements(&ce->constants_table);

While we don't do warnings for unsigned->signed conversion and vice versa; it's still good practice to use the right type.
Also please then change the other count types to unsigned.

smart_str_append_printf(str, "%sCase %s", indent, ZSTR_VAL(name));
if (c->ce->enum_backing_type == IS_UNDEF) {
// No value
smart_str_appends(str, "\n");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
smart_str_appends(str, "\n");
smart_str_appendc(str, '\n');

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants