Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Serializer] Instantiator - Add an interface and default implementation to instantiate objects #38487

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

Closed
wants to merge 3 commits into from

Conversation

Korbeil
Copy link
Contributor

@Korbeil Korbeil commented Oct 8, 2020

Q A
Branch? 5.x
Bug fix? no
New feature? yes
Deprecations? no
Tickets #30818
License MIT
Doc PR symfony/symfony-docs#...

Related to #30818, Replace #30925

This add a new interface and default implementation to instantiate objects

OBJECT_TO_POPULATE was not keep here, as i don't think it should be the responsability of an instantiator to handle that. And if we want to have this responsability we can always add a new implementation with a decoration system.

I try to look at var exporter instantiator also and unfortunetaly @nicolas-grekas i cannot use this, since the behavior of this component is to not use the constructor, in the serializer we want to use it, or at least it used to do that and we cannot change this behavior.

But we can use var exporter implementation in a future PR (will not be the default however just another way of doing it) here if someone does not want to call the constructor.

PS: This PR is following #30956 after main branch moved from master to 5.x

TODO

@Korbeil Korbeil force-pushed the feature/instantiator branch 2 times, most recently from 0c3913b to a572179 Compare October 9, 2020 14:13
@Korbeil Korbeil force-pushed the feature/instantiator branch from a572179 to fd03ce5 Compare October 11, 2020 17:16
@Korbeil
Copy link
Contributor Author

Korbeil commented Oct 11, 2020

I fixed all tests related to this PR, last errors are related to 5.x branch errors.
Ready for review 😉

@nicolas-grekas nicolas-grekas added this to the 5.x milestone Oct 12, 2020
@Korbeil Korbeil force-pushed the feature/instantiator branch 2 times, most recently from f9e4d11 to 847de48 Compare October 12, 2020 20:07
@Korbeil Korbeil force-pushed the feature/instantiator branch 3 times, most recently from 460e883 to 701cd0f Compare October 16, 2020 16:47
Comment on lines +183 to 193
public function setDenormalizer(DenormalizerInterface $denormalizer)
{
$this->denormalizer = $denormalizer;

// Because we need a denormalizer in the Instantiator and we create it in the construct method, it won't get it.
// So we are obliged to overwrite this method in order to give the denormalizer to the Instantiator.
$this->instantiator->setDenormalizer($denormalizer);
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is the strange part. Instantiator needs a denormalizer to work, this is why this class has the DenormalizerAwareInterface interface. But since the Instantiator can be created in the __construct so it will never receive a denormalizer (the DenormalizerAwareInterface will be catch either by the Serializer or by the DIC, here none of them will be triggered).
So in order to still get that denormalizer, we overwrite the setDenormalizer method here and give the denormalizer to the Instantiator.

Comment on lines +372 to 381
if (!\array_key_exists(Instantiator::INSTANTIATOR_CONSTRUCTOR, $context)) {
$context[Instantiator::INSTANTIATOR_CONSTRUCTOR] = \Closure::fromCallable([$this, 'getConstructor']);
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Compatibility layer for the old getConstructor function

@Korbeil Korbeil force-pushed the feature/instantiator branch from 701cd0f to 224c8c6 Compare October 17, 2020 09:20
@Korbeil Korbeil force-pushed the feature/instantiator branch 3 times, most recently from 2301613 to 093ce3a Compare October 20, 2020 17:57
@theofidry
Copy link
Contributor

@Korbeil I've had a quick look at the PR, I think the idea behind is good but I have some concerns about the actual implementation (e.g. the instantiator implementing the normalizer interface). I had to tweak a lot the object normalizer for a project at our company and hope to back-port some of it. I'll try to come up with a PoC for it and maybe we can combine our efforts there (although this will probably be later in the month)

@Korbeil
Copy link
Contributor Author

Korbeil commented Jan 13, 2021

@Korbeil I've had a quick look at the PR, I think the idea behind is good but I have some concerns about the actual implementation (e.g. the instantiator implementing the normalizer interface). I had to tweak a lot the object normalizer for a project at our company and hope to back-port some of it. I'll try to come up with a PoC for it and maybe we can combine our efforts there (although this will probably be later in the month)

Hey @theofidry, glad to have some feedback on this PR.
Actually we talked a lot about it with @dunglas and came to the conclusion that the idea is good but it should be made more step by step to avoid the BC this PR introduce. I didn't had time to work on this (more focus on Jane's AutoMapper actually 😅).
But I'll be glad to talk about it and try to make this move foward, the efforts to make all Serializer concepts extendable is really needed (you can look related issue for more details about what needs to be done).

@theofidry
Copy link
Contributor

@Korbeil agreed;

Checked this on my side, based on our needs I think what is lacking in this PR (although could be introduced progressively) is the extension points for everything the instantiator does:

  • validating & denormalizing a param for a given type
  • validating & denormalizing parameters
  • collecting parameters
  • instantiating the object

But I think the main issue here is that things are so inter-dependent at the moment, it requires more elements to be extracted first (e.g. creating of a default context, child context, extracting attributes...) without which you end up with an instantiator-normalizer like you came up with but which in the end is as bloated.

@fabpot
Copy link
Member

fabpot commented Sep 13, 2023

@Korbeil I've had a quick look at the PR, I think the idea behind is good but I have some concerns about the actual implementation (e.g. the instantiator implementing the normalizer interface). I had to tweak a lot the object normalizer for a project at our company and hope to back-port some of it. I'll try to come up with a PoC for it and maybe we can combine our efforts there (although this will probably be later in the month)

Hey @theofidry, glad to have some feedback on this PR. Actually we talked a lot about it with @dunglas and came to the conclusion that the idea is good but it should be made more step by step to avoid the BC this PR introduce. I didn't had time to work on this (more focus on Jane's AutoMapper actually 😅). But I'll be glad to talk about it and try to make this move foward, the efforts to make all Serializer concepts extendable is really needed (you can look related issue for more details about what needs to be done).

Based on the latest comment here, I think it's time to close this PR.

@fabpot fabpot closed this Sep 13, 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.

8 participants