The current Hash::maxDimensions function calls Hash::dimensions to try
to get the maximum depth of the passed in array. However, this ends up
only getting the depth of the first element of each 1st dimension
element in the array passed to maxDimensions. The function needs to be
called recursively in order to get the depth of ALL of the elements in
all of the dimensions of the passed in array.
I made the maxDimensions function more closely resemble the deprecated
Set::countDim function in order to restore the correct functionality.
This matcher will match anything and is useful when you just want to
traverse through data and you're not too picky.
I've also refactored the conditions to use a case as it is slightly more
readable and uses fewer lines of code.
Refs #6447
Because of the recursion in these functions, processing very large
arrays would take a very long time. I rewrote the functions to
eliminate any unnecessary recursion and function calls. Large arrays
are now processed much faster.
I'm not sure on whether this is a problem with my local app but I have
seen it a couple of times in a couple of projects: Warning (2): Invalid
argument supplied for foreach() [CORE/Cake/Utility/Hash.php, line 52]
I think Hash::get should be able to handle this better rather than
throwing an error in a core Util file.
Refs #3754
Historically [prop=1] has matched prop=true as well. This restores that
and also fixes [prop=0] not finding falsey values.
This makes the typing less strict in Hash::extract() but I don't think
it is unreasonable given PHP's type juggling.
Refs #3288
When using comparison with a boolean, as the filter is a string, we have to convert the data boolean to "boolean string" to avoid type-casting troubles.
## Example
```php
$users = [
[
'id' => 2,
'username' => 'johndoe',
'active' => true
],
[ 'id' => 5,
'username' => 'kevin',
'active' => true
],
[
'id' => 9,
'username' => 'samantha',
'active' => false
],
];
$unactiveUsers = Hash::extract($users, '{n}[active=false]');
print_r($unactiveUsers);
```
This example returns the two unwanted active users because `"false"` is `true` but not `false` :)
I think this pull request will fix this issue by converting true/false boolean to string (to match with our filter).
When the key + value counts do not match Hash should throw an exception.
Silently doing the wrong thing is generally not a good idea. While this
change could break existing applications, those applications were
probably behaving incorrectly anyways.
Fixes#2470
