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

New PHP 8.4 Syntax: new MyClass()->method() without parentheses #89

Open
Tracked by #97
KorvinSzanto opened this issue Jul 12, 2024 · 6 comments
Open
Tracked by #97
Labels
enhancement New feature or request

Comments

@KorvinSzanto
Copy link
Contributor

new Foo()->baz() will be allowed in PHP 8.4, we should cover it in the next version of PER-CS.

To me this is similar to the question of new Foo vs new Foo() where we decided the latter was better for readability: https://github.com/php-fig/per-coding-style/blob/master/spec.md#4-classes-properties-and-methods

@Crell
Copy link
Collaborator

Crell commented Jul 13, 2024

What should we say here? "Favor using the non-parens version if you can", or is there more to say on the matter?

@samdark samdark added the enhancement New feature or request label Jul 14, 2024
@Crell Crell mentioned this issue Sep 3, 2024
9 tasks
@KorvinSzanto
Copy link
Contributor Author

I'm of the opinion that it's simpler to see at a glance that a new instantiation is happening with wrapping parenthesis, but I don't think it's so much of an improvement that it justifies adding the wrapper in every situation.

Given that this is technically existing syntax, we'd need to go to 3.0 (or drop the thinking in #10) in order to add MUST NOT use parenthesis though we could require the opposite opposite since that's backwards compatible. In 2.1 we could add something like:

When chaining new instantiations with method calls (IE new Foo()->baz(), the instantiation - including the new keyword - SHOULD NOT be wrapped in parenthesis. When dealing with a complex statement, wrapping parenthesis MAY be used for readability.

@Crell
Copy link
Collaborator

Crell commented Oct 7, 2024

As usual, I don't think "never use this fancy new syntax that was just approved" is going to fly. The RFC passed 25 to 4. :-) So let's take "MUST NOT" use it off the table, as it's clear people want to use it.

The question is whether we encourage it, or stay silent. I'm leaning toward silent at the moment, but could be convinced otherwise. (We can always say something about it in a future version.)

@KorvinSzanto
Copy link
Contributor Author

As usual, I don't think "never use this fancy new syntax that was just approved" is going to fly. The RFC passed 25 to 4. :-) So let's take "MUST NOT" use it off the table, as it's clear people want to use it.

I agree, but I think you're misinterpreting my comment. I said "MUST NOT use parenthesis" which would mean we advocate for the thing that passed 25 to 4.

I'm saying that we cannot advocate stronger than a SHOULD until 3.0 unless we advocate for the thing that requires no code change, which I agree we shouldn't do.

@Crell
Copy link
Collaborator

Crell commented Oct 7, 2024

Oh! I see what you mean. I'm open to a SHOULD here if the rest of the WG is.

@samdark
Copy link
Member

samdark commented Oct 8, 2024

@Crell sounds more weighted than MUST for the case 👍

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

No branches or pull requests

3 participants