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

Convert PHPEnumType constructor to use config #1621

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

Conversation

shmax
Copy link
Contributor

@shmax shmax commented Oct 18, 2024

With all the activity around enums lately, I thought I'd trot out this old classic from May of last year (I somehow botched the old PR, so this is a do-over). The basic idea is to make the PhpEnumType constructor take a config like all the other ones.

As previously established, this is indeed a breaking change.

Kindly review, thank you.

*
* @throws \Exception
* @throws \ReflectionException
*/
public function __construct(string $enum, ?string $name = null)
public function __construct(array $config)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
public function __construct(array $config)
public function __construct(
string $enumClass,
?string $name = null,
?string $description = null,
?EnumTypeDefinitionNode $astNode = null,
?array $extensionASTNodes = null,
)

How about we introduce the new configurable options in this non-breaking way? Given modern PHP now supports named arguments, it should be even more convenient than using array-based config. Ultimately, we might do the same for all other classes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The problem I'm trying to fix here is the inconsistency in the constructor for this one type. If you want to support named arguments then that's something we should do across the board (although I'm not sure it's a great idea, but that's a discussion for another day), which I hope you agree is out of scope for this change.

If you really want to preserve bc I suppose we could make the first argument something like $enumOrConfig and do some fancy checking at runtime.

Copy link
Collaborator

Choose a reason for hiding this comment

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

The problem I'm trying to fix here is the inconsistency in the constructor for this one type.

In that case, I might consider merging this when making a future release that includes breaking changes. I don't plan on it soon though. And if the plan is to move towards named arguments then, I will most likely not make an intermediary release for this just to fix the inconsistency.

The variant I proposed now is something I would be comfortable merging right now. Even if we ultimately go back to using config arrays everywhere, the breakage won't really be worse when we extend it now.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I implemented the proposed solution in #1623 and released https://github.com/webonyx/graphql-php/releases/tag/v15.17.0. We can discuss potential breaking changes when it comes to it, I might change my mind on using config arrays or named arguments.

@shmax
Copy link
Contributor Author

shmax commented Oct 25, 2024

In that case, I might consider merging this when making a future release that includes breaking changes. I don't plan on it soon though. And if the plan is to move towards named arguments then, I will most likely not make an intermediary release for this just to fix the inconsistency.

I'm cool with waiting for the next major release (it's not currently too tough to work around this issue), but that was the agreement we had the last time I opened a PR to fix this, and it didn't get merged into 15. I'm also agreeable to supporting both formats (param list and single config object) in the interim via runtime checking, but I don't want to bother doing the work if you're just going to pooh-pooh it on some kind of philosophical grounds. Let me know what you think, thanks.

@spawnia
Copy link
Collaborator

spawnia commented Oct 26, 2024

I did not make a breaking release since you opened #1375.

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

Successfully merging this pull request may close these issues.

2 participants