-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[PropertyAccess] consistency in createPropertyAccessor #19040
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
Conversation
Travis failure unrelated to these changes. |
* | ||
* @return PropertyAccessor The new property accessor | ||
*/ | ||
public static function createPropertyAccessor($throwExceptionOnInvalidIndex = false, $magicCall = false) | ||
public static function createPropertyAccessor($magicCall = false, $throwExceptionOnInvalidIndex = false, CacheItemPoolInterface $cacheItemPool = null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
those properties should not exist as well because that is where the builder should be used. otherwise this static method is just a wrapper around the constructor of PropertyAccessor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The order of $magicCall
and $throwExceptionOnInvalidIndex
shouldn't be inverted (it's a BC break).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
otherwise this static method is just a wrapper around the constructor of PropertyAccessor.
It was already before, just more restrictive due to the missing arguments.
Also I understand your point of view about the usefulness of this, but most of time there is no need of the builder itself because these arguments are defined once only when getting the PropertyAccessor instance. IMO the builder should be used to deal with differently configured property accessor, enabling features via the builder methods rather than re-pass all the PropertyAccessor constructor args each time you want to change one of its properties..
Plus I don't see the value of creating a PropertyAccessorBuilder instance + adding an additional method call (getPropertyAccessor()
) that does exactly the same logic that new PropertyAccessor(...)
does.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So is this change a BC break? (inversed args)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chalasr : No it isn't, as you introduced them in https://github.com/symfony/symfony/pull/18977/files#diff-223e0a8a8125ad444ff1668096eeb7deR28, which targets the same branch in development.
I guess @dunglas was simply not aware of that, which mislead him.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ogizanagi exactly.
02905a3
to
1e5eea1
Compare
Closing as #18977 has been reverted. |
This adds the missing
$cacheItemPool
argument toPropertyAccess::createPropertyAccessor()
next to #18977 .Also, rather than using the PropertyAccessorBuilder to get a PropertyAccessor instance and make one method call per argument (feature enabling), it directly calls
new PropertyAccessor
with all the method arguments passed.About @Tobion comment in 18977 Please have a look to the doc PR, it now presents all features enabling from
createPropertyAccessor
arguments and documents thePropertyAccessorBuilder
as the right way to get multiple property accessors independently configured.