Skip to content

[PropertyAccess] fix adder/setter priority #29350

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 1 commit into from

Conversation

karser
Copy link
Contributor

@karser karser commented Nov 27, 2018

Q A
Branch? 3.4
Bug fix? yes
New feature? no
BC breaks? it fixes BC break introduced by #28966
Deprecations? no
Tests pass? no, so far it is a reproducer
Fixed tickets #29340
License MIT

@karser
Copy link
Contributor Author

karser commented Nov 27, 2018

I reverted (locally) changes from #28966 and I'm trying to fix it differently.

@xabbuh indeed, the problem is in getWriteAccessInfo()
Instead of checking whether the property itself is plural or single, it checks if the passed $value an array:
image
The problem is that when isWritable is called - it doesn't have $value and an empty array is passed, just as a stub.
image

I added a check if the property name plural. So it uses adder/remover only if the property name is actual plural.

That is - $camelized preserves its original form (plural of singular), $singluars doesn't have plural by design.
So if $singulars contain the original passed value - we 100% sure the singular is meant here. And vice versa. So we can't use it for adder/remover because plural is required here.
Tests pass locally.

@xabbuh @nicolas-grekas makes sense?

image

@xabbuh
Copy link
Member

xabbuh commented Nov 27, 2018

my idea to fix the issue would be #29355

@karser
Copy link
Contributor Author

karser commented Nov 27, 2018

@xabbuh I see - it shouldn't cache the getWriteAccessInfo result without taking into account $value.
But still it doesn't distinguish, for example, isPropertyWritable('email') and isPropertyWritable('emails') they both will be calling getWriteAccessInfo with an empty array argument. I think that the property name should tell whether it's plural or singular.

What do you think of this approach?

$plural = empty(array_intersect(array($camelized), $singulars));
$useAdderAndRemover = $plural && (\is_array($value) || $value instanceof \Traversable)

antograssiot added a commit to antograssiot/core that referenced this pull request Nov 27, 2018
antograssiot added a commit to antograssiot/core that referenced this pull request Nov 27, 2018
antograssiot added a commit to antograssiot/core that referenced this pull request Nov 27, 2018
@nicolas-grekas nicolas-grekas changed the title [PropertyAccess] Added reproducer for adder/setter priority #29340 #28966 [PropertyAccess] fix adder/setter priority Nov 29, 2018
@@ -707,6 +708,16 @@ private function getWriteAccessInfo($class, $property, $value)
$camelized = $this->camelize($property);
$singulars = (array) Inflector::singularize($camelized);

if ($useAdderAndRemover && !\in_array($camelized, $singulars)) {
Copy link
Member

Choose a reason for hiding this comment

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

unfortunately, this does not work for words where singular and plural are the same (aircraft for example)

Copy link
Member

Choose a reason for hiding this comment

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

see the added test in #29355

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, there is a lot of exceptions That are Both Plural and Singular. Although I'm still confused why an empty array is passed to getWriteAccessInfo(). Just to implicitly allow adder/remover?

Copy link
Member

Choose a reason for hiding this comment

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

Probably something like that, though I don't know for sure. Maybe the git history reveals some more background information.

@nicolas-grekas
Copy link
Member

Closing in favor of #29355, thanks for your help!

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.

4 participants