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

Skip to content

[Serializer] Argument objects #19277

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 14 commits into from
Jul 11, 2016
Merged

Conversation

theofidry
Copy link
Contributor

@theofidry theofidry commented Jul 3, 2016

Q A
Branch? 3.1
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? TODO
Fixed tickets none
License MIT
Doc PR TODO

Assuming with have the two following entities:

namespace AppBundle\Entity;

class Dummy
{
    public function __construct(int $id, string $name, string $email, AnotherDummy $anotherDummy)
    {
        $this->id = $id;
        $this->name = $name;
        $this->email = $email;
        $this->anotherDummy = $anotherDummy;
    }
}

class AnotherDummy
{
    public function __construct(int $id, string $uuid, bool $isEnabled)
    {
        $this->id = $id;
        $this->uuid = $uuid;
        $this->isEnabled = $isEnabled;
    }
}

Doing the following will fail:

$serializer->denormalize(
    [
        'id' => $i,
        'name' => 'dummy',
        'email' => '[email protected]',
        'another_dummy' => [
            'id' => 1000 + $i,
            'uuid' => 'azerty',
            'is_enabled' => true,
        ],
    ],
    \AppBundle\Entity\Dummy::class
);

with a type error, because the 4th argument passed to Dummy::__construct() will be an array. The following patch checks if the type of the argument is an object, and if it is tries to denormalize that object as well.

I'm not sure if it's me missing something or this is a use case that has been omitted (willingly or not), but if it's a valuable patch I would be happy to work on finishing it.

@@ -319,9 +319,13 @@ protected function instantiateObject(array &$data, $class, array &$context, \Ref
$params = array_merge($params, $data[$paramName]);
}
} elseif ($allowed && !$ignored && (isset($data[$key]) || array_key_exists($key, $data))) {
$params[] = $data[$key];
// don't run set for a parameter passed to the constructor
unset($data[$key]);
Copy link
Member

Choose a reason for hiding this comment

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

Why removing the unset?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

bad copy/paste, should be kept

@dunglas
Copy link
Member

dunglas commented Jul 3, 2016

This case was omitted when adding deserialization support for complex relations (in 3.1). IMO it should be merged in 3.1.

Can you add a test for this?

*
* @return object
*
* @throws RuntimeException
*/
protected function instantiateObject(array &$data, $class, array &$context, \ReflectionClass $reflectionClass, $allowedAttributes)
protected function instantiateObject(array &$data, $class, array &$context, \ReflectionClass $reflectionClass, $allowedAttributes, $format = null)
Copy link
Member

@dunglas dunglas Jul 3, 2016

Choose a reason for hiding this comment

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

Sorry I realized that this is a BC break... It should be removed. But it's annoying because some normalizers may depend of the format (normalizers of API Platform for instance).

An alternative approach:

  • Rename this method instantiateComplexObject (with the new parameter, it can be movec before $context for consistency)
  • Add back instantiateObject with the current signature and call instantiateComplexObject inside it with format as null
  • Deprecate instantiateObject

WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

will do

@theofidry
Copy link
Contributor Author

theofidry commented Jul 3, 2016

Hm, looks like this also occurs for setters but this is a bigger problem: the serializer leave the set part to the property accessor, so it doesn't have access to the mutator and can't guess the type.

@theofidry theofidry force-pushed the feature/param-object branch from 7b86d12 to e64e999 Compare July 3, 2016 21:13
*
* @return object
*
* @throws RuntimeException
*/
protected function instantiateObject(array &$data, $class, array &$context, \ReflectionClass $reflectionClass, $allowedAttributes)
protected function instantiateComplexObject(array &$data, $class, array &$context, \ReflectionClass $reflectionClass, $allowedAttributes, $format = null)
Copy link
Member

Choose a reason for hiding this comment

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

It can now be:

instantiateComplexObject(array &$data, $class, $format, array &$context, \ReflectionClass $reflectionClass, $allowedAttributes)

To mimic the SerializerInterface::deserialize prototype.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

my bad I kept the old signature, will change it

Copy link
Contributor

Choose a reason for hiding this comment

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

What do you think about using instantiateClass to have something shorter but still clear ?

@theofidry
Copy link
Contributor Author

@dunglas not sure where the problem lies right now, will have to dig a bit into it later although I hope there won't be any big change.

@theofidry
Copy link
Contributor Author

@dunglas tests are passing

@@ -269,6 +269,15 @@ protected function getConstructor(array &$data, $class, array &$context, \Reflec
}

/**
* @see instantiateComplexObject
* @deprecated Since 3.1, will be removed in 4.0. Use instantiateComplexObject instead.
Copy link
Member

Choose a reason for hiding this comment

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

missing @trigger_error() call for this

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@xabbuh done

*/
protected function instantiateObject(array &$data, $class, array &$context, \ReflectionClass $reflectionClass, $allowedAttributes)
{
@trigger_error(sprintf('"%s()" has been deprecated sin Symfony 3.1 and will be removed in version 4.0. Use "%s::instantiateComplexObject()" instead.', __METHOD__, __CLASS__));
Copy link
Contributor

@GuilhemN GuilhemN Jul 5, 2016

Choose a reason for hiding this comment

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

since version 3.2 and @trigger_error(sprintf('...'), E_USER_DEPRECATED);

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm quite surprised this went undetected by the phpunit bridge...

Copy link
Member

Choose a reason for hiding this comment

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

@theofidry phpunit bridge only discovers deprecated errors, not general silenced errors.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@wouterj but I have a test with the @legacy group, so I guess I expected it to warn me or throw me an error if no deprecation notice were discovered

@theofidry
Copy link
Contributor Author

Updated

}

if ($constructor->isConstructor()) {
return $reflectionClass->newInstanceArgs($params);
} else {
Copy link
Contributor

@GuilhemN GuilhemN Jul 6, 2016

Choose a reason for hiding this comment

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

Should not be updated imo as this is less clear...

Copy link
Contributor Author

@theofidry theofidry Jul 6, 2016

Choose a reason for hiding this comment

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

The more indent you have the harder it is to read. And if the choice is to use if/else/elseif blocks, then everything should be in an else instead of the return done L311.

Copy link
Contributor

@GuilhemN GuilhemN Jul 6, 2016

Choose a reason for hiding this comment

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

There is only one line here and i agree that most of the time else +return is only redundant but here it highlights the fact that one of this line will be executed and that the second one is not just a default.

Edit: BTW, we could reverse the condition if ($constructor) to have less lines indented as you said :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Edit: BTW, we could reverse the condition if ($constructor) to have less lines indented as you said :)

I like this one :)

Copy link
Contributor

Choose a reason for hiding this comment

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

But not sure this would be accepted as this is a small detail and could create many merge conflicts.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah actually I think I'll revert everything for that part, it's just CS and although I think it makes a big difference it terms of readability, I fear that it will cause lots of conflicts later on. One solution would be do go back in earlier versions and fix that version after version, but it's rather tedious and slow.

@@ -47,7 +47,7 @@ public function denormalize($data, $class, $format = null, array $context = arra
$normalizedData = $this->prepareForDenormalization($data);

$reflectionClass = new \ReflectionClass($class);
$object = $this->instantiateObject($normalizedData, $class, $context, $reflectionClass, $allowedAttributes);
$object = $this->instantiateComplexObject($normalizedData, $class, $context, $reflectionClass, $allowedAttributes, $format);
Copy link
Contributor

Choose a reason for hiding this comment

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

Unfortunatelly this looks like a bc break as people may depend on the call to instantiateObject.

Copy link
Contributor Author

@theofidry theofidry Jul 6, 2016

Choose a reason for hiding this comment

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

Not sure to see what you mean, before it was simply failing so people could not used it. The method has been changed because there's a BC break in the method signature (we are adding $format), but the behaviour is the same as the previous one.

Copy link
Contributor

@GuilhemN GuilhemN Jul 6, 2016

Choose a reason for hiding this comment

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

In case someone extends instantiateObject it won't be called anymore. I'll provide you an example of how this could be managed.

Copy link
Contributor

@GuilhemN GuilhemN Jul 6, 2016

Choose a reason for hiding this comment

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

You could do something like:

protected function instantiateObject(..., $allowedAttributes/**, $format*/)
{
    $format = null;
    if (func_num_args() >= 6) {
        $format = func_get_arg(5);
    }

    // ...
}

protected function instantiateComplexObject(...)
{
    static $deprecationTriggered = false;
    if (false === $deprecationTriggered) {
        $deprecationTriggered = true;
        $class = get_class($this);
        if (0 !== strpos($class, 'Symfony\\') 
            && self::class !== (new \ReflectionMethod($this, 'instantiateObject'))->getDeclaringClass()->getName()) {
            @trigger_error(..., E_USER_DEPRECATED);
        }
    }

    return $this->instantiateObject(...);
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

taking $format as the 6th argument in instantiateObject would still be a problem if you extended it

Copy link
Member

Choose a reason for hiding this comment

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

This is forbidden by the PHP interpreter itself: https://3v4l.org/S48gf
Si there is no problem here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

When you override a protected method, you must respect its contract... It's not a BC break for me.

If you override it this way there is not BC as the added param is optional.

In all honesty I would be happy to say yes to this solution it's the easiest way to deal with it really. The only thing I'm worried about is that it may introduce a BC break (but that's up to you to decide if it is or not) and the fact that the user may not see the change (i.e. see that he has to inject the format now).

Copy link
Member

@dunglas dunglas Jul 10, 2016

Choose a reason for hiding this comment

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

Anyway, it's not a BC break because the parent function is still called with the good number of arguments. See https://3v4l.org/XpYGK.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nvm, even with my example it wouldn't be a problem as you would call the parent function with the right number of parameters. Not doing so is looking for trouble and would be the developer fault.

Copy link
Contributor

Choose a reason for hiding this comment

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

This solution is often used in symfony so i'd say it's not part of the symfony bc promises.

@dunglas
Copy link
Member

dunglas commented Jul 10, 2016

Status: Reviewed

👍 when tests for PHP <7 will be fixed

@dunglas
Copy link
Member

dunglas commented Jul 11, 2016

Thank you @theofidry.

@dunglas dunglas merged commit 988eba1 into symfony:master Jul 11, 2016
dunglas added a commit that referenced this pull request Jul 11, 2016
This PR was merged into the 3.2-dev branch.

Discussion
----------

[Serializer] Argument objects

| Q             | A
| ------------- | ---
| Branch?       | 3.1
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | TODO
| Fixed tickets | none
| License       | MIT
| Doc PR        | TODO

Assuming with have the two following entities:

```php
namespace AppBundle\Entity;

class Dummy
{
    public function __construct(int $id, string $name, string $email, AnotherDummy $anotherDummy)
    {
        $this->id = $id;
        $this->name = $name;
        $this->email = $email;
        $this->anotherDummy = $anotherDummy;
    }
}

class AnotherDummy
{
    public function __construct(int $id, string $uuid, bool $isEnabled)
    {
        $this->id = $id;
        $this->uuid = $uuid;
        $this->isEnabled = $isEnabled;
    }
}
```

Doing the following will fail:

```php
$serializer->denormalize(
    [
        'id' => $i,
        'name' => 'dummy',
        'email' => '[email protected]',
        'another_dummy' => [
            'id' => 1000 + $i,
            'uuid' => 'azerty',
            'is_enabled' => true,
        ],
    ],
    \AppBundle\Entity\Dummy::class
);
```

with a type error, because the 4th argument passed to `Dummy::__construct()` will be an array. The following patch checks if the type of the argument is an object, and if it is tries to denormalize that object as well.

I'm not sure if it's me missing something or this is a use case that has been omitted (willingly or not), but if it's a valuable patch I would be happy to work on finishing it.

Commits
-------

988eba1 fix tests
98bcb91 Merge pull request #1 from dunglas/theofidry-feature/param-object
7b5d55d Prevent BC in instantiateObject
e437e04 fix reflection type
3fe9802 revert CS
5556fa5 fix
d4cdb00 fix CS
93608dc Add deprecation message
f46a176 Apply patch
f361e52 fix tests
4884a2e f1
e64e999 Address comments
e99a90b Add tests
7bd4ac5 Test
@theofidry theofidry deleted the feature/param-object branch July 11, 2016 08:15
@theofidry
Copy link
Contributor Author

You're welcome ;)

@fabpot fabpot mentioned this pull request Oct 27, 2016
dunglas added a commit that referenced this pull request Dec 6, 2016
This PR was merged into the 3.2 branch.

Discussion
----------

[Serializer] Fix argument object denormalization

| Q             | A
| ------------- | ---
| Branch?       | 3.2
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #20670
| License       | MIT
| Doc PR        | N/A

Fixes #20670. I've seen #19277 (diff) so I think it's the right thing to do, but I didn't follow the thread at the time, so I may have missed something.

Ping @theofidry, @dunglas.

Commits
-------

27de65a [Serializer] Fix argument object denormalization
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.

6 participants