New PHP 8.4 Syntax: Property Hooks

[KorvinSzanto]

Property hooks are landing in 8.4, the next version of PER-CS should cover them:

class Foo
{
    public function __construct(private User $user) {}

    public string $userName {
        get {
            return $this->user->userName;
        }
    }
}

[Crell]

Unsurprisingly, my recommendation is for the style used in the RFC. Including allowing get to be all inline if it's an abbreviated get.

public string $userName { get => $this->user->userName; }

[TimWolla]

Unsurprisingly, my recommendation is for the style used in the RFC.

That brace placement would be inconsistent with methods, which have a newline before the opening brace.

[Crell]

That's true. However:

1. The point of hooks is to make coding easier and more compact for common cases. That means not forcing extraneous newlines where we don't have to.
2. The RFC used inline and no one objected at that time.
3. Control structures all use same-line braces. The spec is already inconsistent.
4. PSR-2's decision to require a newline for classes and methods/functions was incredibly stupid, misguided, based on a bad representation of the data, and made without any regard for language consistency. It's the dumbest part of these coding standards, and the only reason we haven't changed it is because the breakage would be massive. Please, let's not continue that stupidity. :smile:

[jrfnl]

The RFC used inline and no one objected at that time.

Sorry, but that really is a non-argument. People read and evaluate RFCs for the functionality which is being proposed. The code style used to present that functionality is absolutely irrelevant to an RFC and discussing that on the internals mailing list would be waved away within seconds.

PSR-2's decision to require a newline for classes and methods/functions was incredibly stupid, misguided, based on a bad representation of the data, and made without any regard for language consistency. It's the dumbest part of these coding standards, and the only reason we haven't changed it is because the breakage would be massive. Please, let's not continue that stupidity.

The language used here is pretty strong and IMO comes across as disrespectful to the people involved in that decision.

Whether you agree with decisions taken in the past or not, is irrelevant.

Code style is all about consistency and making thing easier to read. Advocating for deliberate inconsistency just because you don't agree with a past decision is not a good argument to back up a proposal.

If you don't agree with a past decision, challenge that decision and propose to change it, but don't make a code guideline inconsistent.

[edorian]

Just my 2 cents and my heuristics on the matter having read the RFC, played with the 8.4RCs and prepared a couple of slides with code examples for talks.

Instinctively, both examples discussed here feel formatted correctly, the longform example only feels correct because I prefer braces on the same line for functions. Which clashes with how all other code looks.

Longform

With that in mind, I'd say for this standard to be consistent, the formatting could look like this:

    public string $userName
    {
        get
        {
            return $this->user->userName;
        }
        set (string $name)
        {
            $this->user->userName = $name;
        }
    }

Which I find very lengthy personally.

    public string $userName
    {
        get {
            return $this->user->userName;
        }
        set (string $name) {
            $this->user->userName = $name;
        }
    }

Feels more natural like a “function” (string $username properties) and an inline statement “get” inside that “function”.

Short closures / Arrow Syntax

public string $userName { get => $this->user->userName; }

Also feels ok and fitting to me.

• match expressions are written in one line and this looks similar to that
• We already have arrays with only a single element being written inline as well

Short closure with more than one accessor.

My main question would be on using both a set and a get with short syntax. The new line after $userName again feels fitting with the rest of the standard, despite my person preference.

public string $userName 
{ 
    get => $this->user->userName;
    set (string $name) => $this->user->userName = $name;
}

Summary

For me, the above feels consistent with how we treat single element arrays vs. multi-element arrays.

Reopening the discussion for this standard on “new line before { in general” doesn't feel productive and is something people can overrule on a per-project basis if need be.