-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Hash::extract() is transforming values. #8053
Comments
I don't see how this is a defect. It sounds like a change in behavior that would break existing applications. There haven't been any changes to Hash since Oct 2015, so the behavior has been consistent for quite some time. |
Is there an alternative to not force the objects to break into arrays upon simple Hash read? |
What do you mean by 'force the objects to break into arrays'? Are you getting the array cast of an object instead of the object? Does the object in question implement |
It is our CakePHP Time object, see the linked issue in CsvView. |
Odd, I don't really get what is going on in that other issue, but are you attempting to extract a property out of an entity and the property's value is a Time instance? |
And after extracting it is an array, not a Time instance, making it impossible to work on it anymore. |
Might be because of this line. |
@josegonzalez No, it doesnt even run into the isset() check |
The problem is
This should only be done for iterable items we whitelist, not for all possible objects IMO. But this cannot be changed in 3.x, unless we add an additional option to prevent this from happening to any object, e.g. |
I added a small test case to show the intuitive ("late toArray transformation") expectation: 3.next...3.2-hash So the
transformation is only necessary for the last case, where we on purpose go deeper. |
For the test cases you have shown following code isn't executed:
This is what's executed:
So when using |
Thank you, you are right. This makes it more complicated. I guess virtual field hacks are the only viable workaround I can think of so far. We would need a new method otherwise that does not cast to array but keeps the found value as is. |
Hash::get() is available and works as expected, from what I just tried. |
Probably instead of
it should be
|
That sounds reasonable, but a too harsh BC break for a 3.x release I am afraid. But to avoid nesting of arrays maybe:
|
IMO existing behavior is a bug, but yeah people could be relying in this behavior. |
@dereuromark Your suggestion sounds like it should work well. |
Is this fixable in 3.x? Or shall this wait until 4.x? |
Turn the "correct behavior" it on by a an option flag. Set the flag as default in 4.x? |
Unfortunately it does not seem trivial to fix.. Any ideas? |
Leave it alone? 😄 |
Naaaaah ;) That's still an ugly bug - as ugly as those new smileys. |
@ADmad After some trying around I finally found a viable solution that can land in 3.5.0. |
I think Hash::extract() does too much, it should maybe not convert the value itself into an array, but rather return it completely.
This would allow for string casts afterwards, whereas right now it would need information on how the array structure of each transformed object looks like.
Example case: FriendsOfCake/cakephp-csvview#55
We just want the User.created DateTime object from the entity, so we can pass it to _renderRow().
But instead the array of it is returned and we can never transform it again as string without deep knowledge of the structure of this specific array.
Might be a side effect of recent changes, maybe a regression even.
The text was updated successfully, but these errors were encountered: