8000 [Serializer] Add types to private and internal properties by derrabus · Pull Request #45721 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

[Serializer] Add types to private and internal properties #45721

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

Merged
merged 1 commit into from
Apr 19, 2023

Conversation

derrabus
Copy link
Member
Q A
Branch? 6.1
Bug fix? no
New feature? no
Deprecations? no
Tickets N/A
License MIT
Doc PR N/A

This PR adds types to private and @internal properties of the serializer component. This time, I've also applied CPP and readonly flags where possible. If this makes the review too hard or there are other reasons not to do that, please tell me and I'll skip it in future PRs.

8000 @carsonbot
Copy link

Hey!

I think @mtarld has recently worked with this code. Maybe they can help review this?

Cheers!

Carsonbot

@fabpot fabpot modified the milestones: 6.1, 6.2 May 20, 2022
Copy link
Member
@nicolas-grekas nicolas-grekas left a comment

Choose a reason for hiding this comment

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

Friendly ping @derrabus

I'm just wondering about those array-key and array<Foo>: don't we prefer using Foo[]? /cc @wouterj since you're on a similar topic these days :)

For the record, I'm not sold on blindly using readonly on private properties: the keyword breaks legit use cases (lazy proxies) for little to no practical benefits.

@wouterj
Copy link
Member
wouterj commented Jul 28, 2022

I'm just wondering about those array-key and array<Foo>: don't we prefer using Foo[]?

I agree about array-key: afaik this is the default and I don't see a point in explicitly providing it.

I'm not sure about array<...> vs ...[] syntax. I would say the code-base currently "prefers" [] merely because the other syntax didn't exist a few years ago.

I prefer array<>, as using array<Foo> and array<string, Foo> seems more consistent to me than using Foo[] and array<string, Foo>. And I don't like Foo[][] when nesting arrays :)

@nicolas-grekas nicolas-grekas modified the milestones: 6.2, 6.3 Nov 5, 2022
@nicolas-gre
8000
kas
Copy link
Member

Friendly ping @derrabus )

@nicolas-grekas nicolas-grekas force-pushed the types/serializer branch 2 times, most recently from bbaabc3 to 63bb48e Compare April 19, 2023 14:04
@nicolas-grekas
Copy link
Member

Thank you @derrabus.

@nicolas-grekas nicolas-grekas merged commit f709c6e into symfony:6.3 Apr 19, 2023
@derrabus derrabus deleted the types/serializer branch April 19, 2023 14:09
@derrabus
Copy link
Member Author

Thank you for completing it.

* @param array<DecoderInterface> $decoders
*/
public function __construct(
private readonly array $decoders = []
Copy link
Member

Choose a reason for hiding this comment

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

I think I've said this before, but strictly speaking this is a BC break: the $decoders property has no longer a default value (the default value is given to the parameter only).
This creates issues when overriding the constructor without calling the parent as the property becomes uninitialized: https://3v4l.org/DId0c

Is this something we consider too much of an edge case, or would this be a reason against transforming everything to CPP?

Copy link
Member

Choose a reason for hiding this comment

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

This has already beaten us at least once so this is a valid concern to me.

@wouterj wouterj mentioned this pull request Dec 28, 2023
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.

5 participants
0