I would love to see those improvements as well, however I am surprised
we seem to be more inclined to push a more substantial change than a
minor one.
I feel like the more substantial one would be more likely to break
stuff, compared to the minor one, and so I don't see why the minor one
would be refused?
That said, I am new here, and I do not yet know how things work, so it
probably is because I lack experience.
On Thu, Jul 18, 2024 at 3:50 PM Larry Garfield <[email protected]> wrote:
>
> On Thu, Jul 18, 2024, at 10:11 AM, Oliver Nybroe wrote:
> > Thanks for sharing previous discussions, I will definitely take a look
> > at those before writing up the RFC.
> >
> >
> >> If you do with to go with an RFC, I'd like to see if your proposal
> > addresses whether this syntax should implicitly call
> > parent::__construct(), and if a semi colon is expected or not
> > (public function __construct(public int $foo); vs `public function
> > __construct(public int $foo)`).
> > Thank you, these are very valuable points to address in the RFC.
> >
> > I can definitely feel that there will be some mixed opinions about
> > semicolon vs no semi colon.
> >
> >
> > Best regards
> > Oliver Nybroe (he/him)
>
> Please don't top-post.
>
> Since the last time this came up, PSR-12 has been replaced with PER-CS, which as of 2.0 now
> says:
>
> > If a function or method contains no statements or comments (such as an empty no-op
> > implementation or when using constructor property promotion), then the body SHOULD be abbreviated as
> > {} and placed on the same line as the previous symbol, separated by a space.
>
> cf: https://www.php-fig.org/per/coding-style/#44-methods-and-functions
>
> (I... suppose technically it doesn't mention classes, but I've been doing it for
> empty classes too.)
>
> So the "coding style" part of the previous issue has been resolved. Whether that
> changes anyone's mind about whether this should be done or not is up to them to decide.
>
> Personally, I'd probably vote for it if it came up, but I agree it's a pretty minor
> improvement and unlikely to pass. It would probably only be worth doing if there were other
> common-pattern-optimizations around the constructor that came with it. Things like auto-forwarding
> to the parent, or a more compact syntax than a full constructor method, or other things that make
> writing a "pure data" product type easier rather than just s/{}/;/
>
> I don't know what those could look like. As a data point, in Kotlin (which is what my day
> job is now), constructor properties are always promoted, essentially.
>
> class Foo(val a: String, val b: String) { // This is the equivalent of PHP's promoted
> properties.
>
> val c: Int = 5 // A non-constructor-initialized property. These can have hooks, constructor
> ones I think cannot.
>
> init {
> // This is the non-promoted part of a constructor body, and runs after the properties are
> assigned.
> }
> }
>
> In case of inheritance, there's dedicated required syntax for forwarding to the parent:
>
>
> class Foo(val a: String, val b: String) : Bar(b) { // equivalent to parent::__construct($b)
>
> }
>
> You can also make the constructor private (etc.) with more explicitness:
>
> class Foo private constructor(val a: String, val b: String) {}
>
> Of note, if there's no constructor then the parens are omitted, and if there's no
> body then the {} body is omitted. That means a great many "value objects"/DTOs, etc just
> look like this:
>
> class Foo(
> val a: String,
> val b: String,
> )
>
> Which would be equivalent to PHP's
>
> class Foo {
> public function __construct(
> public readonly string $a,
> public readonly string $b.
> ) {}
> }
>
> cf: https://kotlinlang.org/docs/classes.html
>
> To be clear, I'm not suggesting PHP just copy Kotlin directly. I'm saying that if we
> want to improve the constructor syntax for common cases, which I am open to, we should be looking to
> do something more substantial and ergonomic than just replacing {} with ;, and we could probably get
> some good inspiration from other languages in our family. (Java, Kotlin, C#, Swift, etc.)
>
> --Larry Garfield