feat: support object values in array dot helpers

[syawqy]

Description

Fixes #10225.

This PR updates array_group_by() so it can group rows that are objects, such as rows returned by json_decode() or object-based result sets.

Previously, the internal grouping helper required each row to be an array and used dot_array_search(), which also only accepts arrays. That caused a type error when grouping an array of stdClass objects.

The change keeps the public helper API unchanged and adds internal dot-path lookup support for array/object rows. Grouped rows are preserved as their original type, so object rows remain objects in the result.

Regression tests were added for:

• Grouping stdClass rows by a direct property.
• Grouping object rows by a nested dot path.

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value (without duplication)
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[mergeable]

Hi there, syawqy! 👋

Thank you for sending this PR!

We expect the following in all Pull Requests (PRs).

• PRs must be sent to the appropriate branch
• All git commits must be GPG-signed
• Must follow our style guide
• Be commented in the PHP source file
• Be documented in the user guide
• Be unit tested
• Pass all checks in GitHub Actions

Important

We expect all code changes or bug-fixes to be accompanied by one or more tests added to our test suite to prove the code works.

If pull requests do not comply with the above, they will likely be closed. Since we are a team of volunteers, we don't have any more time to work
on the framework than you do. Please make it as painless for your contributions to be included as possible.

See https://github.com/codeigniter4/CodeIgniter4/blob/develop/contributing/pull_request.md

Sincerely, the mergeable bot 🤖

[patel-vansh]

Thanks for the PR. I think object handling in array helper's dot syntax is not being implemented anywhere in the ArrayHelper. I don't know if its indented or not, but if this PR gets merged, we would require follow-up PRs for other methods as well.

[michalsn]

Thank you for sending a PR. Unfortunately, it cannot be merged in its current form.

Since this would be an enhancement rather than a bug fix, it should target the 4.8 branch. Also, as mentioned above, support for arrays of objects should be considered consistently across the other array methods/helpers that currently support only arrays of arrays.

[syawqy]

Thanks for the review. I have updated the PR to target the 4.8 branch and revised the implementation so object support is handled in the shared array dot syntax path instead of only in array_group_by().

The PR now covers object values for dot_array_search(), dot_array_has(), dot_array_only(), and array_group_by() through the same internal lookup behavior.

Tests and analysis passed:

• vendor/bin/phpunit tests/system/Helpers/ArrayHelperTest.php tests/system/Helpers/Array/ArrayHelperDotHasTest.php tests/system/Helpers/Array/ArrayHelperDotModifyTest.php
• composer analyze

[syawqy]

Docs have been updated to describe object property support for the array dot read operations and array_group_by(), including the v4.8.0 changelog entry.

[patel-vansh]

I think we should explicitly mention in a note something like: Prior to v4.8.0, Only array of arrays were supported. Support for objects was added in v4.8.0

[patel-vansh]

Also, in a general sense, I am quite unsure if helper methods like dot_array_* should support objects or not? Array of objects maybe supported, but if we start accepting objects in dot_array_search(), then will the function name itself justify it?

[syawqy]

That concern makes sense. I agree the docs should be explicit that this is new in v4.8.0 and limited to read-style dot traversal.

My reasoning for keeping object support here is that this does not turn the array helper into a general object mutation API. It only allows dot-path reads to traverse public object properties in the same way they traverse array keys. This matches common inputs such as json_decode() results, where rows are often stdClass objects by default.

Also, the Array Helper already documents object support for array_sort_by_multiple_keys(), so supporting arrays containing objects is not entirely new to this helper. The mutating helpers like dot_array_set() and dot_array_unset() remain array-focused.

[patel-vansh]

My reasoning for keeping object support here is that this does not turn the array helper into a general object mutation API. It only allows dot-path reads to traverse public object properties in the same way they traverse array keys. This matches common inputs such as json_decode() results, where rows are often stdClass objects by default.

Also, the Array Helper already documents object support for array_sort_by_multiple_keys(), so supporting arrays containing objects is not entirely new to this helper. The mutating helpers like dot_array_set() and dot_array_unset() remain array-focused.

I guess you're right, we could add support for objects in ArrayHelper. Well actually, most of the time, it'll be used with array of objects and that is mostly intended, so, it would be okay.

[michalsn]

We can't rely on get_object_vars() as it ignores magic properties, __get(), __isset(), toRawArray(), toArray(), and ArrayAccess-style objects.