Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[Serializer] Object class resolver#28669

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation

@alanpoulain
Copy link
Contributor

@alanpoulainalanpoulain commentedOct 1, 2018
edited by nicolas-grekas
Loading

QA
Branch?master
Bug fix?no
New feature?yes
BC breaks?no
Deprecations?no
Tests pass?yes
Fixed tickets
LicenseMIT
Doc PR

When normalizing an object, it could be useful to use a custom method to resolve the class name of it instead of usingget_class.
For instance, Doctrine is using proxy classes for lazy-loading and we usually want the real class and not the proxied one.
That's why we are using this trait in API Platform:https://github.com/api-platform/core/blob/master/src/Util/ClassInfoTrait.php
With this feature, we could solve an issue in API Platform with the JSON-LD normalizer when the eager fetching is disabled.


publicfunction__construct(ClassMetadataFactoryInterface$classMetadataFactory =null,NameConverterInterface$nameConverter =null,PropertyTypeExtractorInterface$propertyTypeExtractor =null,ClassDiscriminatorResolverInterface$classDiscriminatorResolver =null)
/**
* @var ObjectClassResolverInterface|null

Choose a reason for hiding this comment

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

can't we make it a callable and remove the interface instead?

dunglas reacted with thumbs up emoji
/**
* @var ObjectClassResolverInterface|null
*/
protected$objectClassResolver;

Choose a reason for hiding this comment

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

should be private

Copy link
Member

Choose a reason for hiding this comment

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

And the docblock can be removed

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Can't it be useful to have it in the child classes?

Choose a reason for hiding this comment

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

it's still catchable by overriding the constructor in child classes
but we don't want to promise BC regarding any changes that could happen after instantiation.

alanpoulain and jvasseur reacted with thumbs up emoji
@nicolas-grekasnicolas-grekas added this to thenext milestoneOct 1, 2018
/**
* @var ObjectClassResolverInterface|null
*/
protected$objectClassResolver;
Copy link
Member

Choose a reason for hiding this comment

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

And the docblock can be removed

*/
protected$objectClassResolver;

publicfunction__construct(ClassMetadataFactoryInterface$classMetadataFactory =null,NameConverterInterface$nameConverter =null,PropertyTypeExtractorInterface$propertyTypeExtractor =null,ClassDiscriminatorResolverInterface$classDiscriminatorResolver =null,ObjectClassResolverInterface$objectClassResolver =null)
Copy link
Member

@dunglasdunglasOct 1, 2018
edited
Loading

Choose a reason for hiding this comment

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

If you switch to acallable, you can just set'\get_class' as default value, then you can remove the ternary operator later.

Choose a reason for hiding this comment

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

Although that might be slower

dunglas reacted with thumbs up emoji
@alanpoulain
Copy link
ContributorAuthor

I have used a callable instead of an interface.
For the sake of performance, I have kept the ternary.

dunglas reacted with thumbs up emoji

Copy link
Member

@nicolas-grekasnicolas-grekas left a comment

Choose a reason for hiding this comment

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

(with minor comment)

$stack =array();
$attributes =$this->getAttributes($object,$format,$context);
$class =\get_class($object);
$class =$this->objectClassResolver ?\call_user_func($this->objectClassResolver,$object) :\get_class($object);

Choose a reason for hiding this comment

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

could be written as($this->objectClassResolver)($object)

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

I've copied what was done for themaxDepthHandler.

$attributeValue =\call_user_func($this->maxDepthHandler,$attributeValue,$object,$attribute,$format,$context);

It seems to me there is no important difference between the two ways of doing it:https://stackoverflow.com/questions/1596221/php-call-user-func-vs-just-calling-function/35031466

Copy link
Member

Choose a reason for hiding this comment

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

($this->objectClassResolver)($object) is more elegant, but indeed being consistent is good

@dunglasdunglasforce-pushed theserializer-object-class-resolver branch fromeb5d8d4 to18d2143CompareOctober 3, 2018 20:34
@dunglas
Copy link
Member

Thanks@alanpoulain for working on this feature, this is much appreciated.

alanpoulain reacted with thumbs up emoji

@dunglasdunglas merged commit18d2143 intosymfony:masterOct 3, 2018
dunglas added a commit that referenced this pull requestOct 3, 2018
This PR was squashed before being merged into the 4.2-dev branch (closes#28669).Discussion----------[Serializer] Object class resolver| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | yes| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets || License       | MIT| Doc PR        |When normalizing an object, it could be useful to use a custom method to resolve the class name of it instead of using `get_class`.For instance, Doctrine is using proxy classes for lazy-loading and we usually want the real class and not the proxied one.That's why we are using this trait in API Platform:https://github.com/api-platform/core/blob/master/src/Util/ClassInfoTrait.phpWith this feature, we could solve an issue in API Platform with the JSON-LD normalizer when the eager fetching is disabled.Commits-------18d2143 [Serializer] Object class resolver
@nicolas-grekasnicolas-grekas modified the milestones:next,4.2Nov 1, 2018
This was referencedNov 3, 2018
$classDiscriminatorResolver =newClassDiscriminatorFromClassMetadata($classMetadataFactory);
}
$this->classDiscriminatorResolver =$classDiscriminatorResolver;
$this->objectClassResolver =$objectClassResolver;
Copy link
Contributor

Choose a reason for hiding this comment

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

I know it's late, but how about$this->objectClassResolver = $objectClassResolver >: '\get_class'; or something like that ? So that we don't need to test if it is not null on each call

Copy link
Contributor

Choose a reason for hiding this comment

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

@Taluu : You should provide a PR :)

Taluu reacted with thumbs up emoji
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@dunglasdunglasdunglas approved these changes

@nicolas-grekasnicolas-grekasnicolas-grekas approved these changes

+2 more reviewers

@TaluuTaluuTaluu left review comments

@ogizanagiogizanagiogizanagi left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

4.2

Development

Successfully merging this pull request may close these issues.

6 participants

@alanpoulain@dunglas@Taluu@nicolas-grekas@ogizanagi@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp